* Delete CRUD-DB-Table-Template-Application.json
* Updated Template
* Update TC to replace selectedRow with triggeredRow as per the updated template
Co-authored-by: Abhijeet <ABHI.NAGARNAIK@GMAIL.COM>
* -set user photo id when adding a new comment thread
* -update user data when users remove their profile photo
* -updated photo id in comments when user changes or set a profile photo
* -remove photoid from thread, kept it in comment only
* -resized uploaded profile image
* -added test for delete profile photo
* -add test for the comment set user photo
* -check user change event handler is called in delete user photo
* -add test for checking user photo change event is triggered after upload photo
* -fixed tests due to changes
* -make profile pictures thumbnail only
* - used get photo by asset id API to show user photo in comment card
- set cache control header in get asset by id API
* - stop using email address to show user photo
* Adding handling for columns with multiple words in name
* Maintaining the order of columns by using LinkedHashMap instead of Map
* Incorporating review comments
* Migrating the test from Set to List to assert the order of the columns as well in the response
The env config API currently only changes values that are already defined in the env file. It is not capable of adding anything to the file.
This commit adds the capability to do so. However, since we don't want to let the client add just any variable, we've switched from a black list to a white list of env variables that can be managed by this API. If the requested variable is present in the whitelist, we add it, if its missing in the env file.
This commit adds the following API:
`/api/v1/admin/env` — Responds with the names and values of all environment variables currently configured, that are allowed for configuration from the UI. Some variables will be missing from this, ones that are not allowed to be edited from the configuration UI.
Doesn't take any query params. Only usable by the superuser.
Also added a `isSuperUser` boolean field to the response of `api/v1/users/me`, that will indicate whether the current user is a superuser or not.
* Currently, the list of actions to be run on page load is not updated when an action object gets deleted. Hence, sometimes, a previously deleted action may be set to run on page load which throws an error when the application tries to run it on page load.
* This PR updates the list of actions to be run on page load whenever any action gets deleted.
The problem was that the pagination was designed & tested with only 2 pages. Firestore has a different function `limitToLast` which solves for previous page pagination commands.
