Portfolio invitations do not associate a user entity until the
invitation has been accepted. User info, including DOD ID, is held on
the invitation itself. When a user accepts and invitation, their user
entry is associated with the corresponding `portfolio_role` entry.
The same change will be applied to `application_role` and application
invitations. For now, small changes have been made to
application-related methods so that that flow works as-is.
In the future, an `application_invitation1 will not refer to a `user` until
someone accepts the invitation; they'll only reference an
`application_role`. When a user is invited to an application, the
inviter can specify the environments the invitee should have access to.
For this to be possible, an `environment_role` should reference an
`application_role`, because no `user` entity will be known at that time.
In addition to updating all the models and domain methods necessary for
this change, this commit deletes unused code and tests that were
dependent on `environment_roles` having a `user_id` foreign key.
This gives us better test isolation. Previously, we were manually
setting `g.current_user` with a factory instance and not cleaning it up
properly, which could break later tests.
Use ApplicationRole.id instead of User.id in forms. This eliminates the
need for the function that checks whether a user is in a given
application, because looking up the application role will raise an error
if the user is not.
- Adds a property to ApplicationRole model so that it knows its related
EnvironmentRole models.
- Rewrite the form data builder in the routes file so that it loops the
application members and their environment roles to build the data
structure.
Our forms should rely on role IDs for displaying user information on the
portfolio page. This way they are decoupled from user table data and can
eventually rely on invitation user data where an invitation has been
sent but a user does not exist yet.
