Cleaning up user organizations

[mdbenjam]

Problem

We currently have a mishmash of ways in which we control who is in each organization. For example:

• Attorney <-> Judge team mappings are stored in Constants::AttorneyJudgeTeams
• Co-located team for round robin purposes is stored in Constants::CoLocatedTeams
  • Co-located is also retrieved from VACOLS using the condition staff_record.stitle == "A1" || staff_record.stitle == "A2"
• Dispatch is determined four our pilot by Constants::BvaDispatchTeams
  • Dispatch is also determined from VACOLS using the condition staff_record.sdept == "DSP"
• Attorneys are determined by the presence of a sattyid in VACOLS
• VSOs are determined by their roles in BGS

This complex web is difficult to track, not particularly extensible, and requires a deploy to change.

We've generally abided by the principle that it's best to rely on VACOLS for this information. However, VACOLS poses two problems. 1) VACOLS doesn't actually store team information for a lot of users. Lowell in talking with Jed has had to ask him to add people for Quality Review. 2) VACOLS doesn't provide a clean way of allowing a person to be on multiple teams.

Solutions

I propose a new way to keep track of user relationships to organizations. I know we've been reluctant to manage users <-> organization mappings in Caseflow because there is a new contract out to manage the HR system within VACOLS. While ideally this team would eventually handle this problem, I think we need an interim solution that allows us to easily change these team mappings.

I see two options: 1) Maintain all organization information in a giant ruby hash:

{
  <organzation1>: [<user1>, <user2>, ...],
  <organzation2>: [<user1>, <user2>, ...],
  ...
}

2) Maintain this mapping in the DB. Create an OrganizationalUser join table that stores this mapping. And build a simple UI to manage it. The UI would look like this:

[Organizations | Users] <- Toggle button to show list of organizations or users

Organization 1:
   - User 1
   - User 2
   - [Add User] <- Text box to add users

Organization 2:
   - User 1
   - User 3
   - [Add User] <- Text box to add users

--------- User version of the page --------

User 1: Organization1, Organization2, [Add Organization] <- Text box to add organization
User 2: Organization1, Organization3, [Add Organization] <- Text box to add organization

I lean towards option 2 for a few reasons 1) It allows us to store this relationship information in our DB which lets us simply use ActiveRecord magic to understand the relationships. user.organization and organization.users simply work. 2) It allows us to outsource maintenance of user <-> organization relationships to someone at the Board. 3) While it's more work than the other method of consolidation, I do not think building this UI will take more than a few days.

Caveats

1) Long term I'd like to migrate judges to their own organizations so we can consolidate our generic queue work with the judge <-> attorney relationship. 2) Which organization VSOs are part of will always need to be managed via BGS as that's their system of record. However, which users are part of a VSO can be managed in Caseflow since BGS does not provide an endpoint for this information.

[lowellrex]

I second everything Mark proposes here with the slight exception that I think he may be downplaying how much of a pain relying on VACOLS for team membership information is.

[amprokop]

Sounds good to me.

My only hesitation is maintaining redundant lists of users— it would be a little confusing if VACOLS and Caseflow have competing lists of users in group X.

If we need to introduce many new organizations at this point, then it may make sense to do this!

However, I want to propose an option 3 as well— maintaining the list of users in source control in the appeals-deployment repo, maybe in a more friendly format like YAML.

Advantages:

• Auditability comes for free
• Transparency comes for free
• Code reviews mean mistakes are less likely
• We can manage organizations like we do features or functions, and reuse some/most of that code as well
• Can have support staff manage this.
• Doesn't require a deploy, Jenkins job applies updates

Disadvantages:

• Much harder to outsource this to a Board user

I'd be curious to hear from @laurjpeterson — is management of organization users something that we would and could outsource to the Board?

[amprokop]

But happy to go with whatever approach makes sense, with the caveat that maybe we could start off with the lightest weight option and defer building a UI until outsourcing is imminent.

[mdbenjam]

How easy is it to setup the Jenkins job that pulls from one of these YAML files? It's not something I've done before so I don't know how difficult it is. Presumably it's mostly just copying and pasting from the existing ones.

There are definitely some advantages to option 3. One downside, however, is option 3 doesn't lend itself to eventually be outsourced. i.e. building a UI in Caseflow around a yml file is harder than building a UI around DB entries.

Probably just because it's something I'm familiar with, but building a UI for option 2 feels about as simple for me as creating a new Jenkins job. Since I really haven't done that before. But I understand your hesitation with doing anything outside our already large scope.

Curious what Lauren thinks about our ability to outsource this.

[lowellrex]

I prefer option 2 because I think the other two options merely attempt to approximate the mapping table that we would be implementing in option 2. The goal of this effort is to establish the relationship between users and organizations in the Caseflow application. The users and organizations are currently identified in the users and organizations tables in the caseflow database so it seems natural that we would continue to use that database to establish the relationship between them.

[lpciferri]

I think this is something we could feasibly outsource to the Board, but we'd have to pitch it.

• Someone in the Front Office already updates a BVA-wide org chart. They could do this too.
• BVA is looking for a special counsel to replace Dustin. This might not be the most exciting task for that position, but it's possible we could provide reasons for it to be part of it

However, I could also see BVA thinking that it is the responsibility of the branch/organization chief to keep this updated. Like, the Hearing Branch chief would update their list of employees. Or, judges keep their attorneys up to date. And, I think this is more feasible than one person keeping all of BVA updated. But, it could increase risk of many people updating this source of truth.

To explore the idea, could option 2 lend itself at all to Hearing Branch chief navigating to the configuration UI, but only being able to update the Hearing Branch organization?

Another option would be someone like Jennifer Jessup, who is over all Board admin teams, being able to update their org/teams and someone like Jebby Rasputnis, senior counsel to DVC Osborne keeping attorneys/judges up to date.

[mdbenjam]

What do you think about letting anyone within an organization add a member to that organization? At least for now? We would just have to add the first user to each organization and then they can add the rest. In the future we could create an admin role where only administrators could do it. But I don't think that's necessary at first. These are relatively small organizations, I don't see people intentionally messing things up.

[amprokop]

obligatory notification that scope creep is happening :)

On Wed, Oct 17, 2018 at 18:40 Mark Benjamin notifications@github.com wrote:

What do you think about letting anyone within an organization add a member to that organization? At least for now? We would just have to add the first user to each organization and then they can add the rest. In the future we could create an admin role where only administrators could do it. But I don't think that's necessary at first. These are relatively small organizations, I don't see people intentionally messing things up.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/department-of-veterans-affairs/caseflow/issues/7427#issuecomment-430814297, or mute the thread https://github.com/notifications/unsubscribe-auth/ADm0y2DD0rhQoTfDAuw1T92y-PeZeK8Tks5ul7HqgaJpZM4XkNfw .

[mdbenjam]

I actually think just building an organizations/<org-url>/users endpoint is possibly simpler than the initial proposal. As long as we leave out thinking of permission-ing, or the only permission-ing we have is that you have to be a member of the organization itself.

[amprokop]

Hmm are you saying that it’s simpler than your proposed option 1? I’m not sure I understand how.

[amprokop]

Oh maybe your proposed option 2. Sure, sounds good. Just try to consider the lowest-cost option when deciding what to do, but whatever you go with is fine 👍

[lpciferri]

Sounds good to me too.