notifications-routing merge requestshttps://gitlab.cern.ch/push-notifications/notifications-routing/-/merge_requests2022-05-09T09:19:28+02:00https://gitlab.cern.ch/push-notifications/notifications-routing/-/merge_requests/102[HOTFIX] Issue handling unique usernames when username is None2022-05-09T09:19:28+02:00Emmanuel Ormancey[HOTFIX] Issue handling unique usernames when username is NoneCloses #
expanding the channel members and groups to build the total list of (unique) target users
unicity was built on usernames which creates issues when it's none, and in addition it's looking for existing users in the DB based on t...Closes #
expanding the channel members and groups to build the total list of (unique) target users
unicity was built on usernames which creates issues when it's none, and in addition it's looking for existing users in the DB based on the username, which fails when None (exception thrown)
Closes #70Emmanuel OrmanceyEmmanuel Ormanceyhttps://gitlab.cern.ch/push-notifications/notifications-routing/-/merge_requests/113[#75] Auditing fixes2023-01-30T14:45:48+01:00Carina Antunes[#75] Auditing fixesFrom the issue:
- [ ] For users - only audit username and email
- [x] For egroups - audit group identifier (instead of uuid)
- [x] Channel snapshot - avoid calling target groups and users inside (its confusing)
- [x] Computed users for ...From the issue:
- [ ] For users - only audit username and email
- [x] For egroups - audit group identifier (instead of uuid)
- [x] Channel snapshot - avoid calling target groups and users inside (its confusing)
- [x] Computed users for intersection - it's confusing (in reality its duplicated from channel snapshot, so perhaps we can just add the key total to it
- [x] Unsubscribed users is being audited twice
Closes #75
Last comment [merge_requests/110#note_6299000](https://gitlab.cern.ch/push-notifications/notifications-routing/-/merge_requests/110#note_6299000):
> It's still not ready.
I propose we create a new MR with the same branch because it's getting harder and harder to track. Please go over all cases and only mark as ready to review after it's ready.
> I've checked and in the user auditing we're auditing the entire user list (including users from e-groups which we agreed on ommiting for privacy reasons since it's a privacy leak - because someone can add a e-group they don't own and therefor don't have access to the user list but see the info in the auditing), eg [user-audit.json](/uploads/e03554cde619793722aeaf6585605497/user-audit.json). We also agreed for external on only auditing email/username.
> I propose adding thorough test cases to auditing, specially to make sure we don't leak private data in the external audit.
> We're also auditing get group users twice, can we access if we can change the implementation to fetch them only once? eg [internal-direct-group-intersect.json](/uploads/3b92750d0a57e55cffca052a6718c49b/internal-direct-group-intersect.json)Current sprint: Week 34 + 35