department-of-veterans-affairs / caseflow

Caseflow is a web application that enables the tracking and processing of appealed claims at the Board of Veterans' Appeals.
Other
54 stars 19 forks source link

Create database rows for Mail, FOIA, and AOD organizations #7355

Closed lowellrex closed 6 years ago

lowellrex commented 6 years ago

Now that we know how VACOLS identifies members of these teams, all that is left to do in order to give these teams access to the full power of Caseflow is to add the database rows for the Mail, FOIA, and AOD organizations by running the following commands in a production Rails console:

mail_org = Organization.create!(name: "Mail", url: "mail")
StaffFieldForOrganization.create!(organization: mail_org, name: "sdept", values: %w[MPS])

foia_org = Organization.create!(name: "FOIA", url: "foia")
StaffFieldForOrganization.create!(organization: foia_org, name: "sdept", values: %w[AIRS])

aod_org = Organization.create!(name: "AOD", url: "aod")
StaffFieldForOrganization.create!(organization: aod_org, name: "sdept", values: %w[AOD])

We should hold off on doing that until we are ready to pilot because adding those rows will allow anyone who is identified in VACOLS as being a member of any of those teams will have access those organizations' queues.

amprokop commented 6 years ago

Nice! Is it better to add those organizations in a PR so it's more traceable and auditable? Seems like that's the path we were going for before, correct me if I'm wrong or if it seems like a lot of work!

lowellrex commented 6 years ago

I don't have a strong opinion either way though I do lean slightly in favor of just doing these changes live. I see the benefit of documenting this in a Rails migration, but there is also the downsides of those changes being slow to make (have to wait for a code review, CI build to pass, and deployment to come along and push the changes live) and less flexible to changes (will we create a Rails migration if a team at the Board wants their name changed?).

Losing the documentation benefit of these changes being in a PR is a bummer, but the rows we are adding will be very limited (1 row in 2 different tables that I don't expect to ever have more than a few dozen rows) so inspecting the contents of those tables should reveal whatever information we'd want to know.

amprokop commented 6 years ago

Yeah. Not concerned with this particular instance, just concerned with treating this sort of thing as a normal long-term path.

lowellrex commented 6 years ago
  1. We will have to run this process for all VSOs (already done for 15 VSOs which I believe is nearly all we expect to use Caseflow at this point) and for all teams at the Board (2 already done, I think there are somewhere on the order of 20 teams), so I don't think we would need to do this more than 20 times. If we expect to do this more frequently then I think the argument for doing additions to the database manually (or through some in-app UI perhaps?) would be even stronger since the Rails migration process is quite cumbersome.

  2. I'm not sure what mistakes are not possible when running Rails migrations that are possible when entering statements directly in the Rails console. As for us being alerted to mistakes, in either case I think we would rely on direct observation with pilots or folks letting us know that something isn't working right (I imagine not being able to access an organization's cases view might occur with some regularity).

  3. Adding these rows through Rails migrations would give us this for free which would be great. We could add some of these rows to the seed data which might get us some of the way to solving that problem, but maybe we don't use seed data for all environments? This also might not be such a huge concern since all of the critical path organizations that our application cares about will be referenced in code similar to how the BVA Dispatch team is defined. All of the other organizations will exist simply to show views onto the underlying data in different ways that is otherwise totally agnostic to the application.

lowellrex commented 6 years ago

Closing this issue since we have settled on a new strategy for associating users and organizations: #7506.