jadudm
commented
1 month ago I added numbers to the stories for reference; no other changes made.
First, a few questions. Perhaps the questions lead to more stories.
Questions
- When we remove a user, do we have an auditable history of who was associated with the audit and for what period of time? That is, if I was a certifying official on an audit from the time of its creation to yesterday (when I was removed), is there a table in the FAC where I can discover that?
- Should we have a story for removing someone from all in-progress audits with which they are associated? For a small firm or sole proprietorship, that might be one audit. For a firm, you might be part of a unit that assigns you to 10, 20 or more. The complexity here, of course, is that I could only remove them from all audits with which I am also associated. (I don't like where Q2 just ended up...)
- Do we explicitly check that we are not removing the last person from an audit? Although that seems impossible, if Alice and Bob are both logged in, and they both attempt to remove each-other, we could have a race. Ending up with no one attached to an audit... well, at some level, the fix for having no one attached to an audit is easy: start a new submission. But, it might be a case we want to defend against.
In working through this (above), I hit a point where I think I have some intractables. I'm going to pause to explore an idea. I'll story them as Noodles. Each Noodle has a Response, and then a Reason.
Of Alice, Bob, Clarice, and Wiggie, Xena, Ylonda, and Zeke...
Alice, Bob, and Clarice are attached to audits. There are six audits in the system they are associated with.
Alice is a Auditor Certifying Official at SARU (Single Audits R Us). Bob and Clarice are editors in the firm.
Wiggie, Xena, Ylonda, and Zeke are auditees. Xena has a set of housing companies that all received HUD money, and therefore has to submit several audits. (I don't know if this is possible. It seems like its, from the data. Or, they were incorrectly submitted.)
| Audit | Editors |
|---|---|
| 1 | A, B, C, X |
| 2 | A, B, Y |
| 3 | A, Z |
| 4 | A, B, C, X |
| 5 | A, B, X |
| 6 | A, C, W |
Noodles
Noodle 1: Alice, the Auditor Certifying Official, was caught having fun racing the company Datsun a bit too fast down Santa Monica Boulevard to the phone company parking lot, and is terminated immediately per company policy. Bob is charged with removing Alice from all audits, but is only associated with Xena and Ylonda's audits; he is unaware of the work that Clarice is doing with Wiggie.
Noodle 2: Bob was caught spinning bottles of Bud on the floor of the bar during his lunch break, and is terminated immediately per company policy. Because Alice declared she needed to have some fun (and went on an extended vacation), Clarice needs to remove Bob from all audits with which he is associated. However, she is only associated with Xena's and Wiggie's audits, and can't do anything about either Ylonda's or Zeke's audits.
Noodle 3: Alice was caught moonlighting at the local car wash during her lunch breaks, and was terminated immediately per company policy. Both Bob and Clarice remove Alice from all audits they know of, but did not realize that Alice was personally handling Zeke's audit, because they're old friends, and she's been doing so for years.
We could argue that Noodle 1 can be resolved by Bob and Clarice talking, and working together to remove Alice from all audits. Noodle 2 could be resolved (eventually) when Alice returns, but there is a period of time where Clarice is unable to make sure that Bob cannot do harm. In Noodle 3, neither Bob nor Clarice have any way of knowing that Alice had some "audits on the side."
I'm going to suggest a different model, and see if it resolves these cases. It might be something we need in conjunction with the ability to remove individuals from individual audits.
Responses
Noodle 1 Response: Bob issues a FAC Removal Response (FACRR) on Alice. She is immediately blocked from logging into the FAC for n days. At the same time, the FAC emails everyone associated with audits that Alice was attached to. This means Clarice, Xena, Ylonda, and Zeke all receive notices, being asked to confirm if Alice should be removed from their particular audit. In this way, either Clarice or Wiggie can remove Alice from their audit.
Noodle 2 Response: Clarice issues a FACRR on Bob. If Alice left her work phone at home while on vacation, she would have no way of approving removals. However, Xena and Ylonda would both get notices, and could take action to remove Bob from their audits.
Noodle 3 Response: Because Bob and Clarice are on audits with which Alice is associated, either of them can issue a FACRR. Even though neither of them are on an audit with Zeke, it is still the case that Zeke will get the FACRR; Zeke can remove Alice from his audit.
If a positive response is not received within n days, then all parties are notified that the FACRR is rescinded, and access is re-enabled for the party in question.
In all cases involving Alice, we need to be able to remove the Auditor Certifying Official. While it is true that the audit cannot then be certified... that's OK. The audit should not be able to be certified in that state. Another auditor needs to be found, and what happens from there... either a continuation of the submission, or a new submission, must take place. (In the case of a firm, the audit report is available, and perhaps the submission can continue; in the case of a sole proprietorship, a new auditor and new submission probably needs to be started.)
Reasons
Noodle 1 Reason: This could be solved by communication between Bob and Clarice. But, if the firm is large enough, Bob might have no way of knowing that Clarice even works there, or has audits in common with Alice. A FACRR provides Bob a way of notifying all parties without having to know who those parties are.
Noodle 2 Reason: Clarice has to remove Bob, and she knows Alice could help, but Alice is not accessible. The FACRR raises awareness, and allows the auditees to do the right thing.
Noodle 3 Reason: It is possible in any given context that the parties charged with removing people from in-flight audits have no idea about some of the work they are doing. And, there are plenty of situations where the person who needs to be removed cannot be asked (or trusted to answer completely) about what audits they are associated with. In this case, the FACRR allows for "zero knowledge" on the part of the parties issuing the FACRR, but removal actions can still take place.
All of this assumes an underlying technology like Spiff Workflow, which we have available to us.
tadhg-ohiggins
Access deletion
Areas of impact
Related documents/links
Context
Overview
There are occasional requests from users to remove other users from submissions—that is, to delete the
Accessinstances that allow those other users to view and edit in-progress submissions.This document only deals with in-progress submissions; submissions that have been disseminated are a separate category. The management of disseminated submissions on the intake side may need to be revisited when we deal with resubmission^1.
Current support
Note that while users have names recorded in the system, only user email addresses matter for purposes of authentication/access. Therefore all references to adding/removing/changing a user refer to adding/removing/changing an email address associated with a role.
Any reference to user management is only with respect to a specific submission; users cannot change the access of any users with respect to the application as a whole.
There are three roles:
Users with these roles can all view the entire submission and make edits. Only users with the Auditee Certifying Official and Auditor Certifying Official roles can complete the certification step matching their role.
Submissions may have multiple users with the Audit Editor role, but only one each with the Auditee Certifying Official and Auditor Certifying Official roles.
In addition, submissions must have users for each of the Auditee Certifying Official and Auditor Certifying Official roles, and these cannot be the same user.
Only users with the Audit Editor role can modify access to the submission, and only these operations are possible:
In particular, the following three operations are not supported:
Note that the user who originally created the submission is automatically granted the Audit Editor role. So far, experience suggests that users who create submissions are users who tend to have responsibilities around managing those submissions; this is part of the rationale for restricting access management functions to users with that role.
Removing Audit Editor access
This is the easiest feature to add. It would probably be wise to prevent users from removing their own access to submissions, as this is unlikely to be intentional. Allowing it would almost definitely increase support request volume.
Removing Certifying Official access
Providing this functionality will lead to problems as users attempt to go through the certification steps for their submissions only to discover that no-one on their team is able to access one or both of those steps because those roles have been removed.
For this reason, we will not add this functionality as part of this feature but will evaluate how many requests for this we receive.
User stories
We should support this use case by allowing users with the Audit Editor role to remove other users, including the Certifying Official users.
For the moment, we will not support this use case, but will evaluate how much of a demand there is for removing Certifying Officials without requirement replacement users for their roles.
We should not support this use case within the application; doing so would render us susceptible to various forms of social engineering attacks. We do not have any means of verifying the identities of correspondents, nor of verifying any claims they make about their status with respect to any organization or submission. In cases such as this one, we should require the user to start a new submission and acquire any materials they need from their own organization.
Decision
We will add a feature granting users with the Audit Editor role the ability to remove that role from others.
We will not allow users with the Audit Editor role to remove themselves from that role. (In practice, this will mean that they must add another user with that role, and that user must then remove them.)
We will not add the ability to remove Certifying Official roles without supplying new users for those roles; we will evaluate how many requests we get that are for exactly this operation.
We will not add any out-of-band processes for adding or removing users from submissions.
Consequences
We will have to do the following:
audit.views.manage_submission_access.ChangeOrAddRoleViewto support deletionAccessobject being deleted matches the email of the current user