Like portfolio invitations, now a user is not associated with an
application role until they accept the associated invitation.
- domain method for inviting user to application
- change application route for inviting a member
- ApplicationRole model knows user name from invitation
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.
- 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.
Previously, we were encoding the portfolio_role.user_id as part of the
form data for the portfolio admin page. This was convenient because it
allowed us to easily determine certain display attributes in the
template. Instead, we should rely on the PortfolioRole as the source of
truth for member information. This commit adds:
- Portfolio.owner_role to return the PortfolioRole of the owner
- explicitly passes the PortfolioRole IDs for the PPoC and current user
to the template
- PortfolioRole.full_name for deriving the member name
- remove extra padding from second modal screen
- update modal styles to more closely match designs
- ad `user_name` property to application_role model to fix flash message
- domain method for creating a new application member
- ApplicationInvitations domain class
- nested form for adding a new user that holds user data, application
permission sets, and environment roles
- Invitation service can infer invitation type based on role it's given
- new invitation email templates
- add a base domain class
- extract shared model code to mixin
- rename invitation classes
- invitation model relationship to portfolio_role name is now more
generic "role"
- parent relation will not include applications or environments marked
as deleted
- domain classes will exclude deleted objects from selections
- changed some test factories to use domain_word for resource names,
because they were using person names and it bugged me
