You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@james.apache.org by "chibenwa (via GitHub)" <gi...@apache.org> on 2023/05/11 08:28:29 UTC
[GitHub] [james-project] chibenwa opened a new pull request, #1557: [ADR] 66 Modular user data deletion
chibenwa opened a new pull request, #1557:
URL: https://github.com/apache/james-project/pull/1557
(no comment)
--
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: notifications-unsubscribe@james.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@james.apache.org
For additional commands, e-mail: notifications-help@james.apache.org
[GitHub] [james-project] chibenwa merged pull request #1557: [ADR] 66 Modular user data deletion
Posted by "chibenwa (via GitHub)" <gi...@apache.org>.
chibenwa merged PR #1557:
URL: https://github.com/apache/james-project/pull/1557
--
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: notifications-unsubscribe@james.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@james.apache.org
For additional commands, e-mail: notifications-help@james.apache.org
[GitHub] [james-project] quantranhong1999 commented on a diff in pull request #1557: [ADR] 66 Modular user data deletion
Posted by "quantranhong1999 (via GitHub)" <gi...@apache.org>.
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: notifications-unsubscribe@james.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@james.apache.org
For additional commands, e-mail: notifications-help@james.apache.org