`portfolios.create_member` now just sends an invitation, so it should be
with the invitation routes. This also de-duplicates the function for
sending a portfolio invitation email.
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.
A `before_request` hook queries the database for portfolios, requests,
and task orders based on the route arguments. The resources are added as
attributes on `g`. The portfolio context processor and the access
decorator now rely on those resources being available on `g`.
WIP: find major resources in before_request hook, apply to g
WIP: use g.portfolio for portfolio context processor
WIP: the access decorator should rely on the resources being available on g
- Adds override to portfolio landing page access check to see if user
has access to any applications within the portfolio.
- Route for accepting an application invitation redirects directly to
portfolio applications route.
- Tests ensure application user only sees apps the user has access to on
the portfolio landing page.
- 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"
