Merge branch 'develop' of github.com:RocketChat/Rocket.Chat into pr/1…

…6537-ritwizsinha-Issue#16499

* 'develop' of github.com:RocketChat/Rocket.Chat: (428 commits)
  Regression: Status presence  color (RocketChat#17707)
  [IMPROVE] Remove index files from action-links, accounts and assets (RocketChat#17607)
  [FIX] Remove a non working setting "Notification Duration" (RocketChat#15737)
  Update Apps-Engine version (RocketChat#17706)
  Regression: Click to join button not working (RocketChat#17705)
  [IMPROVE] Always shows the exact match first on user's and room's autocomplete for mentions and on sidebar search (RocketChat#16394)
  [NEW] API endpoint to fetch Omnichannel's room transfer history (RocketChat#17694)
  Fix typo "You aren't part of any channel yet" (RocketChat#17498)
  [IMPROVE] Display status information in the Omnichannel Agents list (RocketChat#17701)
  [NEW] Option to remove users from RocketChat if not found in Crowd (RocketChat#17619)
  [FIX] Elements of  "Personal Access Tokens" section out of alignment and unusable on very small screens (RocketChat#17129)
  Regression: Integrations edit/history crashing (RocketChat#17702)
  [FIX] Allow owners to react inside broadcast channels (RocketChat#17687)
  Regression: User edit form missing fields (RocketChat#17699)
  [FIX] Default filters on Omnichannel Current Chats screen not showing on first load (RocketChat#17522)
  Update Helper.js (RocketChat#17700)
  [FIX] UI KIT Modal Width (RocketChat#17697)
  Update Contributing Guide (RocketChat#17653)
  LingoHub based on develop (RocketChat#17693)
  [NEW] Added custom fields to Add/Edit user (RocketChat#17681)
  ...

.docker/Dockerfile.rhel

@@ -1,6 +1,6 @@
 FROM registry.access.redhat.com/rhscl/nodejs-8-rhel7
 
-ENV RC_VERSION 3.1.0-develop
+ENV RC_VERSION 3.3.0-develop
 
 MAINTAINER [email protected]
 

.eslintignore

@@ -8,7 +8,6 @@ app/katex/client/katex/katex.min.js
 packages/rocketchat-livechat/assets/rocketchat-livechat.min.js
 packages/rocketchat-livechat/assets/rocket-livechat.js
 app/theme/client/vendor/
-app/ui/client/lib/customEventPolyfill.js
 app/ui/client/lib/Modernizr.js
 public/mp3-realtime-worker.js
 public/lame.min.js

.eslintrc

@@ -24,12 +24,21 @@
     "react/jsx-fragments": [
       "error",
       "syntax"
-    ],
+    ]
   },
   "settings": {
-    "react": {
-      "version": "detect",
+    "import/resolver": {
+      "node": {
+        "extensions": [
+          ".js",
+          ".ts",
+          ".tsx"
+        ]
+      }
     },
+    "react": {
+      "version": "detect"
+    }
   },
   "overrides": [
     {
@@ -38,9 +47,9 @@
         "**/*.tsx"
       ],
       "extends": [
-        "@rocket.chat/eslint-config",
         "plugin:@typescript-eslint/recommended",
-        "plugin:@typescript-eslint/eslint-recommended"
+        "plugin:@typescript-eslint/eslint-recommended",
+        "@rocket.chat/eslint-config"
       ],
       "globals": {
         "Atomics": "readonly",
@@ -73,6 +82,10 @@
           "syntax"
         ],
         "@typescript-eslint/ban-ts-ignore": "off",
+        "@typescript-eslint/indent": [
+          "error",
+          "tab"
+        ],
         "@typescript-eslint/no-explicit-any": "off",
         "@typescript-eslint/interface-name-prefix": [
           "error",

.github/CONTRIBUTING.md

@@ -1,42 +1,253 @@
 # Contributing to Rocket.Chat
 
-:+1::tada: First off, thanks for taking the time to contribute! :tada::+1:
+**First off, thanks for taking the time to contribute! :tada::+1:**
 
-The following is a set of guidelines for contributing to Rocket.Chat and its packages, which are hosted in the [Rocket.Chat Organization](https://github.com/RocketChat) on GitHub.
+> There are many ways to contribute to Rocket.Chat even if you're not technical or a developer:
+>
+> * Email us at [email protected] to tell us how much you love the project
+> * Write about us in your blogs
+> * Fix some small typos in our [documentation](https://docs.rocket.chat/contributing)
+> * Become our [GitHub sponsor](https://github.com/sponsors/RocketChat)
+> * Tell others about us and help us spread the word
+>
+> Every bit of contribution is appreciated 🙂 thank you!
+
+The following is a set of guidelines for contributing to Rocket.Chat, which are hosted in the [Rocket.Chat Organization](https://github.com/RocketChat) on GitHub.
 
 __Note:__ If there's a feature you'd like, there's a bug you'd like to fix, or you'd just like to get involved please raise an issue and start a conversation. We'll help as much as we can so you can get contributing - although we may not always be able to respond right away :)
 
-## ECMAScript 2015 vs CoffeeScript
+## Setup
+
+Your development workstation needs to have at least 8GB or RAM to be able to build the Rocket.Chat's source code.
+
+Rocket.Chat runs on top of [Meteor](https://www.meteor.com/). To run it on development mode you need to [install Meteor](https://www.meteor.com/install) and clone/download the Rocket.Chat's code, then just open the code folder and run:
+```shell
+meteor npm install && meteor
+```
+It should build and run the application and database for you, now you can access the UI on (http://localhost:3000)
+
+It's not necessary to install Nodejs or NPM, every time you need to use them you can run `meteor node` or `meteor npm`.
+
+It's important to always run the NPM commands using `meteor npm` to ensure that you are installing the modules using the right Nodejs version.
+
+## Coding
+
+We provide a [.editorconfig](../.editorconfig) file that will help you to keep some standards in place.
+
+### ECMAScript vs TypeScript
+
+We are currently adopting TypeScript as the default language on our projects, the current codebase will be migrated incrementally from JavaScript to TypeScript.
+
+While we still have a lot of JavaScript files you should not create new ones. As much as possible new code contributions should be in **TypeScript**.
 
-While we still have a lot of CoffeeScript files you should not create new ones. New code contributions should be in **ECMAScript 2015**.
+### Blaze vs React
 
-## Coding standards
+We are currently adopting React over Blaze as our UI engine, the current codebase is under migration and will continue. You will still find Blaze templates in our code. Code changes or contributions may need to be made in Blaze while we continue to evolve our components library.
 
-Most of the coding standards are covered by `.editorconfig` and `.eslintrc.js`.
+[Fuselage](https://github.com/RocketChat/Rocket.Chat.Fuselage) is our component library based on React, check it out when contributing to the Rocket.Chat UI and feel free to contribute new components or fixes.
+
+### Standards
+
+Most of the coding standards are covered by ESLint configured at [.eslintrc](../.eslintrc), and most of them came from our own [ESLint Config Package](https://github.com/RocketChat/eslint-config-rocketchat).
 
 Things not covered by `eslint`:
 
-* `exports`/`module.exports` should be at the end of the file
-* Longer, descriptive variable names are preferred, e.g. `error` vs `err`
+* Prefer longer/descriptive variable names, e.g. `error` vs `err`, unless dealing with common record properties already shortened, e.g. `rid` and `uid`
+* Use return early pattern. [See more](https://blog.timoxley.com/post/47041269194/avoid-else-return-early)
+* Prefer `Promise` over `callbacks`
+* Prefer `await` over `then/catch`
+* Don't create queries outside models, the query description should be inside the model class.
+* Don't hardcode fields inside models. Same method can be used for different purposes, using different fields.
+* Prefer create REST endpoints over Meteor methods
+* Prefer call REST endpoints over Meteor methods when both are available
+* v1 REST endpoints should follow the following pattern: `/api/v1/dashed-namespace.camelCaseAction`
+* Prefer TypeScript over JavaScript. Check [ECMAScript vs TypeScript](#ecmascript-vs-typescript)
 
-We acknowledge all the code does not meet these standards but we are working to change this over time.
+#### Blaze
+* Import the HTML file from it's sibling JS/TS file
 
 ### Syntax check
 
 Before submitting a PR you should get no errors on `eslint`.
 
-To check your files, first install `eslint`:
+To check your files run:
+
+```shell
+meteor npm run lint
+```
+
+## Tests
+
+There are 2 types of tests we run on Rocket.Chat, **Unit** tests and **End to End** tests. The major difference is that End to End tests require a Rocket.Chat instance running to execute the API and UI checks.
+
+### End to End Tests
+
+First you need to run a Rocket.Chat server on **Test Mode** and on a **Empty Database**:
+```shell
+# Running with a local mongodb database
+MONGO_URL=mongodb://localhost/empty MONGO_OPLOG_URL=mongodb://localhost/local TEST_MODE=true meteor
+```
+```shell
+# Running with a local mongodb database but cleaning it before
+mongo --eval "db.dropDatabase()" empty && MONGO_URL=mongodb://localhost/empty MONGO_OPLOG_URL=mongodb://localhost/local TEST_MODE=true meteor
+```
+
+Now you can run the tests:
+```shell
+meteor npm test
+```
+
+### Unit Tests
+
+Unit tests are simpler to setup and run. They do not require a working Rocket.Chat instance.
+```shell
+meteor npm run testunit
+```
+
+It's possible to run on watch mode as well:
+```shell
+meteor npm run testunit-watch
+```
+
+<!-- ### Storybook -->
+
+## Before Push your code
+
+It's important to run the lint and tests before push your code or submit a Pull Request, otherwise your contribution may fail quickly on the CI. Reviewers are forced to demand fixes and the review of your contribution will be further delayed.
+
+Rocket.Chat uses [husky](https://www.npmjs.com/package/husky) to run the **lint** and **unit tests** before proceed to the code push process, so you may notice a delay when pushing your code to your repository.
+
+## Choosing a good PR title
+
+It is very important to note that we use PR titles when creating our change log. Keep this in mind when you title your PR. Make sure the title makes sense to a person reading a releases' change log!
+
+Keep your PR's title as short and concise as possible, use PR's description section, which you can find in the PR's template, to provide more details into the changelog.
+
+Good titles require thinking from a user's point of view. Don't get technical and talk code or architecture. What is the actual user-facing feature or the bug fixed? For example:
+
+```
+[NEW] Allow search permissions and settings by name instead of only ID
+```
+
+Even it's being something new in the code the users already expect the filter to filter by what they see (translations), a better one would be:
+
+```
+[FIX] Permissions' search doesn't filter base on presented translation, only on internal ids
+```
+
+## Choosing the right PR tag
+
+You can use several tags do describe your PR, i.e.: `[FIX]`, `[NEW]`, etc. You can use the descriptions below to better understand the meaning of each one, and decide which one you should use:
+
+### `[NEW]`
+
+#### When
+- When adding a new feature that is important to the end user
+
+#### How
+
+Do not start repeating the section (`Add ...` or `New ...`)
+Always describe what's being fixed, improved or added and not *how* it was fixed, improved or added.
+
+Exemple of **bad** PR titles:
+
+```
+[NEW] Add ability to set tags in the Omnichannel room closing dialog
+[NEW] Adds ability for Rocket.Chat Apps to create discussions
+[NEW] Add MMS support to Voxtelesys
+[NEW] Add Color variable to left sidebar
+```
+
+Exemple of **good** PR titles:
 
 ```
-npm install -g eslint
+[NEW] Ability to set tags in the Omnichannel room closing dialog
+[NEW] Ability for Rocket.Chat Apps to create discussions
+[NEW] MMS support to Voxtelesys
+[NEW] Color variable to left sidebar
 ```
 
-Then run:
+### `[FIX]`
+
+#### When
+- When fixing something not working or behaving wrong from the end user perspective
+
+#### How
+
+Always describe what's being fixed and not *how* it was fixed.
+
+Exemple of a **bad** PR title:
 
 ```
-eslint .
+[FIX] Add Content-Type for public files with JWT
 ```
 
-# Contributor License Agreement
+Exemple of a **good** PR title:
+
+```
+[FIX] Missing Content-Type header for public files with JWT
+```
+
+### `[IMPROVE]`
+
+#### When
+- When a change enhances a not buggy behavior. When in doubt if it's a Improve or Fix prefer to use as fix.
+
+#### How
+Always describe what's being improved and not *how* it was improved.
+
+Exemple of **good** PR title:
+
+```
+[IMPROVE] Displays Nothing found on admin sidebar when search returns nothing
+```
+
+### `[BREAK]`
+
+#### When
+- When the changes affect a working feature
+
+##### Back-End
+- When the API contract (data structure and endpoints) are limited, expanded as required or removed
+- When the business logic (permissions and roles) are limited, expanded (without migration) or removed
+
+##### Front-End
+- When the change limits (format, size, etc) or removes the ability of read or change the data (when the limitation was not caused by the back-end)
+
+### Second tag e.g. `[NEW][ENTERPRISE]`
+
+Use a second tag to group entries on the change log, we currently use it only for the Enterprise items but we are going to expand it's usage soon, please do not use it until we create a patter for it.
+
+### Minor Changes
+
+For those PRs that aren't important for the end user, we are working on a better pattern, but for now please use the same tags, use them without the brackets and in camel case:
+
+```
+Fix: Missing Content-Type header for public files with JWT
+```
+
+All those PRs will be grouped under the `Minor changes` section which is collapsed, so users can expand it to check for those minor things but they are not visible directly on changelog.
+
+## Security Best Practices
+
+- Never expose unnecessary data to the APIs' responses
+- Always check for permissions or create new ones when you must expose sensitive data
+- Never provide new APIs without rate limiters
+- Always escape the user's input when rendering data
+- Always limit the user's input size on server side
+- Always execute the validations on the server side even when executing on the client side as well
+
+## Performance Best Practices
+
+- Prefer inform the fields you want, and only the necessary ones, when querying data from database over query the full documents
+- Limit the number of returned records to a reasonable value
+- Check if the query is using indexes, it it's not create new indexes
+- Prefer queues over long executions
+- Create new metrics to mesure things whenever possible
+- Cache data and returns whenever possible
+
+## Contributor License Agreement
+
+To have your contribution accepted you must sign our [Contributor License Agreement](https://cla-assistant.io/RocketChat/Rocket.Chat). In case you submit a Pull Request before sign the CLA GitHub will alert you with a new comment asking you to sign and will block the Pull Request from be merged by us.
 
 Please review and sign our CLA at https://cla-assistant.io/RocketChat/Rocket.Chat

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,11 +1,46 @@
-<!-- INSTRUCTION: Your Pull Request name should start with one of the following tags -->
+<!-- This is a pull request template, you do not need to uncomment or remove the comments, they won't show up in the PR text. -->
+<!-- Your Pull Request name should start with one of the following tags -->
 <!-- [NEW] For new features -->
 <!-- [FIX] For bug fixes -->
 <!-- [BREAK] For pull requests including breaking changes -->
 
-<!-- INSTRUCTION: Inform the issue number that this PR closes, or remove the line below -->
-Closes #ISSUE_NUMBER
+## Proposed changes
+<!-- Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request. If it fixes a bug or resolves a feature request, be sure to link to that issue below. -->
 
-<!-- INSTRUCTION: Link to a https://github.com/RocketChat/docs PR with added/updated documentation or an update to the missing/outdated documentation list, see https://rocket.chat/docs/contributing/documentation/  -->
+## Issue(s)
+<!-- Link the issues being closed by or related to this PR. For example, you can use #594 if this PR closes issue number 594 -->
+
+## How to test or reproduce
+<!-- Mention how you would reproduce the bug if not mentioned on the issue page already. Also mention which screens are going to have the changes if applicable -->
+
+## Screenshots
+
+## Types of changes
+<!-- What types of changes does your code introduce to Rocket.Chat? -->
+<!-- Put an `x` in the boxes that apply -->
+
+- [ ] Bugfix (non-breaking change which fixes an issue)
+- [ ] Improvement (non-breaking change which improves a current function)
+- [ ] New feature (non-breaking change which adds functionality)
+- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
+- [ ] Hotfix (a major bugfix that has to be merged asap)
+- [ ] Documentation Update (if none of the other choices apply)
+
+## Checklist
+<!-- Put an `x` in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code. -->
+
+- [ ] I have read the [CONTRIBUTING](https://github.com/RocketChat/Rocket.Chat/blob/develop/.github/CONTRIBUTING.md#contributing-to-rocketchat) doc
+- [ ] I have signed the [CLA](https://cla-assistant.io/RocketChat/Rocket.Chat)
+- [ ] Lint and unit tests pass locally with my changes
+- [ ] I have added tests that prove my fix is effective or that my feature works (if applicable)
+- [ ] I have added necessary documentation (if applicable)
+- [ ] Any dependent changes have been merged and published in downstream modules
+
+## Changelog
+<!-- CHANGELOG -->
+<!-- Enter HERE a brief text that would go up on the changelog on our releases page -->
+<!-- END CHANGELOG -->
+
+## Further comments
+<!-- If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc... -->
 
-<!-- INSTRUCTION: Tell us more about your PR with screen shots if you can -->