feat(core): restrict modification of createdon and modifiedon #2188
Conversation
packages/core/README.md
Outdated
| @@ -570,6 +570,29 @@ export class UserRepository extends DefaultUserModifyCrudRepository< | |||
| ) | |||
| ``` | |||
|
|
|||
| The repository by default allows to pass back dated or future dates for createdOn and modifiedOn values but to restrict the manual date modification we can pass overridingOptions like this | |||
There was a problem hiding this comment.
| The repository by default allows to pass back dated or future dates for createdOn and modifiedOn values but to restrict the manual date modification we can pass overridingOptions like this | |
| The repository by default does not restrict setting up of createdOn and modifiedOn through API or external sources. However, you can restrict it using the overridingOptions like this |
| @@ -43,6 +46,10 @@ export abstract class DefaultTransactionalUserModifyRepository< | |||
| const uid = currentUser?.userTenantId ?? currentUser?.id; | |||
| entity.createdBy = uid; | |||
| entity.modifiedBy = uid; | |||
| if (this.overridingOptions?.restrictDateModification) { | |||
There was a problem hiding this comment.
why cant we use the second parameter of the method options?: Options. That ways its consistent and easy to implement.
There was a problem hiding this comment.
Using the method's option parameter user will have to make changes in all the method calls
but with this only one change at repo level
There was a problem hiding this comment.
But this introduces a new param whereas we already have such options in method param. The second param is for that purpose only. Moreover, using the method options param gives more flexibility at runtime.
There was a problem hiding this comment.
Now using the coreConfig for decision making
| @@ -34,6 +35,8 @@ export abstract class DefaultTransactionalUserModifyRepository< | |||
| super(entityClass, dataSource); | |||
| } | |||
|
|
|||
| public overridingOptions?: RepositoryOverridingOptions; | |||
There was a problem hiding this comment.
I dont like this approach. This will mean they will have to do it for all the repo files. Why ? We need to support both mechanism. One using options and another using a global config.
There was a problem hiding this comment.
Tried passing an optional config to the repository but it still requires it from the derived class no mater what
making it a Breaking change - hence used this approach
There was a problem hiding this comment.
Now using the coreConfig for decision making
|
gh-2158
Description
restrict modification of createdon and modifiedon
with this the existing functionality will be same
Introducing a service for future use as well so that such type of conditions can be handled in the future while keeping the code clean and easy to understand.
Set the restrictDateModification property in the core configuration to true to enforce date modification restrictions via the API; otherwise, the default behavior will allow unrestricted changes.
Fixes #2158
Type of change
Please delete options that are not relevant.
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Added it to an existing repository and tested it
Checklist: