Assigning groups & permissions to new user signups
When a new user signs up, a new personal organization is created for that user. Default permission groups are created for this personal organization based on the database that contains this information in the `groups` collection with organization name `default-org`. These default groups should NEVER be deleted from the DB.
The user is then assigned to these default groups which allows him/her to administer their personal organization as org admins
would.
Also, the `User` domain object now returns the email ID as the username of the user.
See merge request theappsmith/internal-tools-server!108
The default groups for an organization are created by copying over data from the groups collection with the organizationId 'default-org'. This ensures that we can update the permissions in the DB and add new permissions without any code changes. The new user is then assigned to these groups so that they have all the permissions required to administer the organization.
Also adding a display name for the groups so that the UI can show a different name than the one used internally within the DB to represent the group.
Create personal workspace/organization on user create
Create user now also leads to creation of personal organization for the user. It also gets assigned as the default (current) workspace (or currentOrganizationId)
See merge request theappsmith/internal-tools-server!105
Published page has layout on load actions and layout load actions now.
LayoutOnLoadActions are now being copied to the published version. Now viewing the published page would give all three published datastructures : DSL, Layout Actions, and Layout Load Actions
See merge request theappsmith/internal-tools-server!104
Adding email sending capability when the user resets their password
At the moment, the email sending is sent in the same thread that slows down the API request. Future changes should include:
1. Publish the request to send an email to Redis and actually send the email on subscribe event.
2. Disable the email sending in local environments.
See merge request theappsmith/internal-tools-server!102
Implementing Forgot Password flow + DB based password authentication
Changes include:
1. Create/Update user APIs now use `passwordEncoder` to encode the user password before storing it in the database.
2. Forgot password flow has been added.
3. Added a `PasswordEncoderConfig` to configure the encoder from a single location
4. Moving from in-memory `MapUserDetails` to DB for checking the password for a user during login.
5. Using `WithUserDetails` in all the tests because we now use our custom `User` domain object instead of Spring's `User` object in our session. The earlier implementation in the test cases was using Spring's implementation.
6. Adding a bunch of javadoc comments to `UserServiceImpl`
See merge request theappsmith/internal-tools-server!101
Get actions by pageId & applicationId
Query params "pageId" and "applicationId" can be used on Get call to actions api to all the actions by page Ids and application ids.
See merge request theappsmith/internal-tools-server!99
Checking if the name of the user is not null. Only then inserting it that field into analytics service.
See merge request theappsmith/internal-tools-server!97
Adding query parameters to filter get API calls
Fixes#92
Adding MultiValueMap in the BaseService class to ensure that all controllers support query parameters for the GET API call. Each service will have to handle this independently though. There is no generic default implementation for handling query parameters as of now.
In the Plugin APIs handling the filtering of fetching plugins specifically by type. This should be used as a template implementation to create a generic implementation of this nature to query the db generically for a list of given fields and values. Will make future API implementations much simpler.
See merge request theappsmith/internal-tools-server!91
Adding the base uri for google oauth2 redirect uri
This is required because when we host the server in a docker container, by default the baseUri picked up by Spring security is the DNS name of the appsmith server inside the docker networking bridge. These names may not be valid DNS names that Google can redirect to in the event of a successful Oauth2 login. Hence, we are overriding the base uri with our own uri for each environment.
The customer will have to provide this uri when they host it on their internal networks. This uri must be publicly accessible for Oauth2 to work.
See merge request theappsmith/internal-tools-server!90
This is required because when we host the server in a docker container, by default the baseUri picked up by Spring security is the DNS name of the appsmith server inside the docker networking bridge. These names may not be valid DNS names that Google can redirect to in the event of a successful Oauth2 login. Hence, we are overriding the base uri with our own uri for each environment.
The customer will have to provide this uri when they host it on their internal networks. This uri must be publicly accessible for Oauth2 to work.
Fixing action execution timeout bug which was defaulting the execution timeout to 0 instead of 10.
See merge request theappsmith/internal-tools-server!89
Use page and application names instead of ids
Fixes#85
We now introduce the ability to fetch application & page details via their names and not just with the ids. This is to ensure that the frontend can navigate through pages and applications using just the name. It's a lot more user friendly.
See merge request theappsmith/internal-tools-server!81
Feature/plugin execution timeout
Action execution timeout can now be configured inside actionConfiguration. If the execution takes longer than the configured value (or default 10s) an error with message "Plugin Execution timed out." is returned.
Fixes#61
See merge request theappsmith/internal-tools-server!88
