quantranhong1999 commented on code in PR #1557: URL: https://github.com/apache/james-project/pull/1557#discussion_r1190824733
########## src/adr/0066-modular-user-data-deletion.md: ########## @@ -0,0 +1,52 @@ +# 66. Deleting user data + +Date: 2023-05-11 + +## Status + +Accepted (lazy consensus). + +Implemented. + +## Context + +Regulation like European RGDP involves being able to delete all user data upon requests. Currently there exist some APIs Review Comment: ```suggestion Regulation like European GDPR involves being able to delete all user data upon requests. Currently there exist some APIs ``` ########## src/adr/0066-modular-user-data-deletion.md: ########## @@ -0,0 +1,52 @@ +# 66. Deleting user data + +Date: 2023-05-11 + +## Status + +Accepted (lazy consensus). + +Implemented. + +## Context + +Regulation like European RGDP involves being able to delete all user data upon requests. Currently there exist some APIs +for deleting some data relative for the users but the overall process is complex, requires a good knowlege of James data structures. + +The data is scattered across the database and some sensible items might not be deletable. + +## Decision + +Define a single endpoint to delete all data relative to a user. + +James being modular, we decided to form it under a webadmin task with a modular design. + +Each feature storing user data would then implement `UserDeletionTaskStep`. + +This modular design for migration steps could help developers easier to manage/test each step, and help other tailor +James servers can implement their own steps as well. + +Today, implemented deletion steps are: + +- `RecipientRewriteTableUserDeletionTaskStep`: deletes all rewriting rules related to this user. +- `FiltereUserDeletionTaskStep`: deletes all filters belonging to the user. Review Comment: ```suggestion - `FilterUserDeletionTaskStep`: deletes all filters belonging to the user. ``` ########## src/adr/0066-modular-user-data-deletion.md: ########## @@ -0,0 +1,52 @@ +# 66. Deleting user data + +Date: 2023-05-11 + +## Status + +Accepted (lazy consensus). + +Implemented. + +## Context + +Regulation like European RGDP involves being able to delete all user data upon requests. Currently there exist some APIs +for deleting some data relative for the users but the overall process is complex, requires a good knowlege of James data structures. + +The data is scattered across the database and some sensible items might not be deletable. + +## Decision + +Define a single endpoint to delete all data relative to a user. + +James being modular, we decided to form it under a webadmin task with a modular design. + +Each feature storing user data would then implement `UserDeletionTaskStep`. + +This modular design for migration steps could help developers easier to manage/test each step, and help other tailor +James servers can implement their own steps as well. + +Today, implemented deletion steps are: + +- `RecipientRewriteTableUserDeletionTaskStep`: deletes all rewriting rules related to this user. +- `FiltereUserDeletionTaskStep`: deletes all filters belonging to the user. +- `DelegationeUserDeletionTaskStep`: deletes all delegations from / to the user. +- `MailboxeUserDeletionTaskStep`: deletes mailboxes of this user, all ACLs of this user, as well as his subscriptions. +- `WebPushUserDeletionTaskStep`: deletes push data registered for this user. +- `IdentityUserDeletionTaskStep`: deletes identities registered for this user. +- `VacationUserDeletionTaskStep`: deletes vacations registered for this user. + + +We introduce `fromStep` query parameter that allows skipping previous steps, allowing the operator to resume the username change from a failed step. +This option could ease operators in case the data migration fails in the middle. + +## Consequences + +- Makes it easier to claim RGDP compliance on top of James. Review Comment: ```suggestion - Makes it easier to claim GDPR compliance on top of James. ``` ########## src/adr/0066-modular-user-data-deletion.md: ########## @@ -0,0 +1,52 @@ +# 66. Deleting user data + +Date: 2023-05-11 + +## Status + +Accepted (lazy consensus). + +Implemented. + +## Context + +Regulation like European RGDP involves being able to delete all user data upon requests. Currently there exist some APIs +for deleting some data relative for the users but the overall process is complex, requires a good knowlege of James data structures. + +The data is scattered across the database and some sensible items might not be deletable. + +## Decision + +Define a single endpoint to delete all data relative to a user. + +James being modular, we decided to form it under a webadmin task with a modular design. + +Each feature storing user data would then implement `UserDeletionTaskStep`. + +This modular design for migration steps could help developers easier to manage/test each step, and help other tailor +James servers can implement their own steps as well. + +Today, implemented deletion steps are: + +- `RecipientRewriteTableUserDeletionTaskStep`: deletes all rewriting rules related to this user. +- `FiltereUserDeletionTaskStep`: deletes all filters belonging to the user. +- `DelegationeUserDeletionTaskStep`: deletes all delegations from / to the user. +- `MailboxeUserDeletionTaskStep`: deletes mailboxes of this user, all ACLs of this user, as well as his subscriptions. Review Comment: ```suggestion - `MailboxUserDeletionTaskStep`: deletes mailboxes of this user, all ACLs of this user, as well as his subscriptions. ``` ########## src/adr/0066-modular-user-data-deletion.md: ########## @@ -0,0 +1,52 @@ +# 66. Deleting user data + +Date: 2023-05-11 + +## Status + +Accepted (lazy consensus). + +Implemented. + +## Context + +Regulation like European RGDP involves being able to delete all user data upon requests. Currently there exist some APIs +for deleting some data relative for the users but the overall process is complex, requires a good knowlege of James data structures. + +The data is scattered across the database and some sensible items might not be deletable. + +## Decision + +Define a single endpoint to delete all data relative to a user. + +James being modular, we decided to form it under a webadmin task with a modular design. + +Each feature storing user data would then implement `UserDeletionTaskStep`. + +This modular design for migration steps could help developers easier to manage/test each step, and help other tailor +James servers can implement their own steps as well. + +Today, implemented deletion steps are: + +- `RecipientRewriteTableUserDeletionTaskStep`: deletes all rewriting rules related to this user. +- `FiltereUserDeletionTaskStep`: deletes all filters belonging to the user. +- `DelegationeUserDeletionTaskStep`: deletes all delegations from / to the user. Review Comment: ```suggestion - `DelegationUserDeletionTaskStep`: deletes all delegations from / to the user. ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
