`user_can` function built for Jinja template contexts should check
application, portfolio, and atat level permissions depending on what
resources are available on `g`.
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.
- raise specific invitation type if invite not found in invitation domain classes
- more terse assignments of defaults in invitation service, smh
- terser margin expression for inline input fields
- sass formatting
- use translation for cancel link
- oxford comma for app team management permission explanation
- do not format environment roles with hyphens for role selection
- generalize some additional methods in the invitation domain base class
- use plain atst.models import path
- 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
The environment name will be grayed out until something besides the
default "no access" is selected.
Small changes to the application member subforms:
- filter for "None" as a string
- have nested forms inherit from FlaskForm; each nested form adds its
own validation error flash otherwise if there are validation problems
- 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"
