#5442 - New notification type to let users know when staff SU'd into their account
-
By PDStig
- Added
- 9 views
| Identifier | #5442 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | New notification type to let users know when staff SU'd into their account |
| Status | Closed (rejected) |
| Tags |
Type: Legal compliance / Privacy (custom) |
| Handling member | Deleted |
| Addon | core_cns |
| Description | We should add a new notification type that allows users to be notified when someone uses SU to gain access to their account.
Notification is enabled by default for all users via email and web notifications. While I cannot 100% confirm, given the nature of the GDPR, I can reasonably assume this is something they would require. And even if they did not require this, I believe it is the ethical thing to do to implement such a feature for transparency; users have the right to know when staff access their account via SU especially considering actions done when under SU appear as that member. |
| Steps to reproduce | |
| Additional information | Be sure to document this in the core Privacy Policy hook as well.
Also, make sure the notification clearly documents what this means and that staff do NOT have the user's account credentials (it is a feature that the highest level of staff typically can do). And that if they believe the SU access was not warranted, they should contact (site email address) immediately. The notification should also tell the member who SU'd into their account. Also also, a JavaScript confirmation box should appear when attempting to SU as a member warning of the implications of doing so (member will be notified, and SU is a tool that should never be used without just cause / for ill purposes such as to damage the reputation of members). Make sure this works correctly when hard-coding "keep_su" in the URL as well. |
| Related to | |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments
1) It's always going to be the case that user data could be accessed without them knowing, so it's creating a false sense of privacy by giving a partial picture. Someone can always just look in the database, and in the real world it is going to happen because people look in databases and can't help see what they see. Staff could also always hack the code to remove the feature, so as a user I would also not necessary trust the notification as being particularly accurate.
2) I don't like the basic conception of the implementation. It's hard for me to communicate exactly why I don't like it, but it resolves around some combination of rushed staff just doing boring innocent admin stuff (like checking to see if there's a bug), combined with potentially trigger-sensitive users who respond badly to stuff they don't really understand. I think it's reasonable to try and achieve a balance because "not scaring users" and "not inconveniencing staff" are just as legitimate design considerations as "informing users about data", especially when no data was actually accessed.
I am going to create a new issue that is similar but I think more reasonable and manageable.