In order to create an application with valid permissions, we copy the relevant permissions from the organization of the user. This involves changes to the organizationService and OrganizationRepository as well.
Also moving the argument AclPermission to the custom Repository interface level. This is to ensure that all the service functions can invoke the same repository function with different permissions based on their requirements.
This is present in the BaseRepositoryImpl. In this manner, we can add default conditions to all the basic JPA queries. Now we only need to figure out how to intercept the custom queries to add user details into.
This is to ensure that setting the createdAt nad updatedAt properties by spring-data will still succeed even if the client doesn't provide us with the datasource details.
Creating an embedded datasource for the action
Now the user can create an embedded datasource as well as a saved datasource for the action.
This MR also fixes the import for a curl command by setting defaults when an action is created via the curl command. For now, the curl command only accepts short flags and not the long form flags.
See merge request theappsmith/internal-tools-server!204
We now create another list from the value provided in the properties file. All checks in the codebase are performed against this list. This ensures that there are no NPE and exceptions when the property oauth2.allowed-domains is removed from the properties file.
Correcting the error response returned by the AclFilter to match the ErrorDTO...
Correcting the error response returned by the AclFilter to match the ErrorDTO returned from controller functions
This ensures consistent responses from different parts of our application. The client can then rely on the server to provide a constistent response structure.
See merge request theappsmith/internal-tools-server!194
This ensures consistent responses from different parts of our application. The client can then rely on the server to provide a constistent response structure.
Renaming isPaginated to PaginationType to support different types of pagination on the frontend
If the API is paginated via the table's page number, then the next and prev URLs in the action don't play any role. Those fields are only required when the paginationType is of type URL. In all other scenarios, the action is executed normally.
See merge request theappsmith/internal-tools-server!192
If the API is paginated via the table's page number, then the next and prev URLs in the action don't play any role. Those fields are only required when the paginationType is of type URL. In all other scenarios, the action is executed normally.
Now, regardless of the route with which an organization is created (invitation, signup or self-create by user), the correct groups and permissions are assigned to the user.
We override the SimpleReactiveMongoRepository with our custom implementation to add criteria for filtering soft deleted records.
Also, adding a new function to archive record instead of a hard delete.
