Change Details

1. Ran migration on existing `threadStore` and there was no diff 2. Added "atul" permission to voiced and observed that it was included thanks to migration: https://blob.sh/6b2616.png 3. Removed misc permissions and observed that they were excluded after migration Later in the stack I add test cases that check that `recursivelyUpdateRoles` makes no changes to a "correct" `threadStore` retrieved from the `keyserver` on login AND that `recursivelyUpdateRoles` can construct correct `threadInfo.roles.permission` with all existing role permissions removed (AKA can do it from scratch solely based off of `getRolePermissionBlobs`. WARNING: Right now we're updating `roles.permissions` for `roles` that exist for a given threadType. That means that we can handle updating of `Members` or `Admins` if they already exist for a threadType, but we CAN'T add or remove roles to `threadInfo.roles`... that requires the `keyserver` in order to generate the roleIDs. So we can't quite build up roles/permissions entirely from scratch as we can on the `keyserver`... though I'm not sure how likely it is that we add/remove a role for an existing thread type vs creating a new thread type. Either way, in that scenario the developer introducing the change would be responsible for ensuring there are no inconsistencies and that may involve additional work.

1. Ran migration on existing `threadStore` and there was no diff 2. Added "atul" permission to voiced and observed that it was included thanks to migration: https://blob.sh/6b2616.png 3. Removed misc permissions and observed that they were excluded after migration Later in the stack I add test cases to check that `recursivelyUpdateRoles` makes no changes to a "correct" `threadStore` retrieved from the `keyserver` on login AND that `recursivelyUpdateRoles` can construct correct `threadInfo.roles.permission` with all existing role permissions removed (AKA can do it from scratch solely based off of `getRolePermissionBlobs`. WARNING: Right now we're updating `roles.permissions` for `roles` that exist for a given threadType. That means that we can handle updating of `Members` or `Admins` if they already exist for a threadType, but we CAN'T add or remove roles to `threadInfo.roles`... that requires the `keyserver` in order to generate the roleIDs. So we can't quite build up roles/permissions entirely from scratch as we can on the `keyserver`... though I'm not sure how likely it is that we add/remove a role for an existing thread type vs creating a new thread type. Either way, in that scenario the developer introducing the change would be responsible for ensuring there are no inconsistencies and that may involve additional work.

1. Ran migration on existing `threadStore` and there was no diff 2. Added "atul" permission to voiced and observed that it was included thanks to migration: https://blob.sh/6b2616.png 3. Removed misc permissions and observed that they were excluded after migration Later in the stack I add test cases thatto check that `recursivelyUpdateRoles` makes no changes to a "correct" `threadStore` retrieved from the `keyserver` on login AND that `recursivelyUpdateRoles` can construct correct `threadInfo.roles.permission` with all existing role permissions removed (AKA can do it from scratch solely based off of `getRolePermissionBlobs`. WARNING: Right now we're updating `roles.permissions` for `roles` that exist for a given threadType. That means that we can handle updating of `Members` or `Admins` if they already exist for a threadType, but we CAN'T add or remove roles to `threadInfo.roles`... that requires the `keyserver` in order to generate the roleIDs. So we can't quite build up roles/permissions entirely from scratch as we can on the `keyserver`... though I'm not sure how likely it is that we add/remove a role for an existing thread type vs creating a new thread type. Either way, in that scenario the developer introducing the change would be responsible for ensuring there are no inconsistencies and that may involve additional work.