View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 5442 | Composr | core_cns | public | 2023-11-14 05:47 | 2024-08-04 22:11 |
| Reporter | PDStig | Assigned To | PDStig | ||
| Priority | normal | Severity | feature | ||
| Status | closed | Resolution | won't fix | ||
| Summary | 5442: New notification type to let users know when staff SU'd into their account | ||||
| 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. | ||||
| 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. | ||||
| Tags | Type: Legal compliance / Privacy | ||||
| Attach Tags | |||||
| Time estimation (hours) | |||||
| Sponsorship open | |||||
|
|
Impossible to do without creating infinite loops: get_member was designed to return the SU'd member, and we cannot rely on GLOBALS because keep_su_strict will prevent us from knowing which staff member did the SU at all. Changing any of this will bug-up sessions and member cache. |
|
|
I know this is closed, but I wanted to write that I'm not a fan of this one for a couple of reasons: 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. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2023-11-14 05:47 | PDStig | New Issue | |
| 2023-11-14 05:47 | PDStig | Status | Not Assigned => Assigned |
| 2023-11-14 05:47 | PDStig | Assigned To | => user4172 |
| 2023-11-14 05:48 | PDStig | Tag Attached: Roadmap: v11 | |
| 2023-11-14 05:48 | PDStig | Tag Attached: Type: Legal compliance / Privacy | |
| 2023-11-14 05:49 | PDStig | Additional Information Updated | |
| 2023-11-14 05:51 | PDStig | Additional Information Updated | |
| 2023-11-14 05:53 | PDStig | Additional Information Updated | |
| 2023-11-14 05:54 | PDStig | Additional Information Updated | |
| 2023-11-14 05:57 | PDStig | Relationship added | related to 5443 |
| 2023-11-14 06:01 | PDStig | Additional Information Updated | |
| 2023-11-14 06:02 | PDStig | Description Updated | |
| 2023-11-14 06:03 | PDStig | Description Updated | |
| 2023-11-14 06:05 | PDStig | Additional Information Updated | |
| 2023-11-14 06:07 | PDStig | Additional Information Updated | |
| 2023-12-19 00:37 | PDStig | Status | Assigned => Closed |
| 2023-12-19 00:37 | PDStig | Resolution | open => won't fix |
| 2023-12-19 00:37 | PDStig | Note Added: 0008136 | |
| 2023-12-19 00:37 | PDStig | Note Edited: 0008136 | |
| 2023-12-19 00:37 | PDStig | Tag Detached: Roadmap: v11 | |
| 2024-03-30 03:37 | PDStig | Project | Composr alpha bug reports => Composr |
| 2024-03-30 03:44 | PDStig | Category | General / Uncategorised => core_cns |
| 2024-08-04 22:06 | Chris Graham | Note Added: 0009083 | |
| 2024-08-04 22:11 | Chris Graham | Relationship added | duplicate of 5848 |
