The implementation here is meant to wrap a library of JSON policy
documents. Policies should be added to directories corresponding to
where they will be defined (portfolio, application, environment).
Functionality for parsing portfolio policy definitions is included. When
the policies need to be defined on a management group, the
AzureCloudProvider can iterate the appropriate tier of the policy
manager and add those definitions.
This adds some initial example policies:
- One for region restrictions
- One for service restrictions
Note that the MS ARM team has said that region restrictions may be
controlled by ARM, so that policy might prove unnecessary. The
parameters list for the service restrictions is stubbed for now, pending
the full list.
I also added an internal method for adding policy definitions to a
management group. This method is agnostic about what tier of management
group the policy is being defined at. It requires that a dictionary
representing the properties section of a valid Azure JSON policy
definition be passed as an argument.
Update TaskOrderForm so that it converts empty string for number into None, this was causing an issue where new TOs were being saved with an empty string for the number, which violated the unique constraint.
New designs call for a streamlined New Portfolio page, with far
fewer input options. This commit refactors that page according to those
designs.
Some of the route functions in this commit refer to a "step 1" of creating
a new Portfolio. Though there is no "step 2" right now, the designs call
for a multistep flow for Portfolio creation process, so this commit sets
the stage for that.
When one user disables another's environment role in Azure, sometimes an
exception will be raised. Since we catch the exception and display an
error message to the user, we should also log the exception so that the
error is traceable later.
The application now checks for an environment variable,
OVERRIDE_CONFIG_DIRECTORY. If that value is set, it loops all the files
in the specified directory and checks if their names correspond to known
configuration settings. The contents of any matching files are read and
set as the new configuration value for that setting. This will allow us
to read mounted Azure Key Vault items as config values.
This also moves the functionality for applying environment variables to
the config into an analogous function.
This commit lays out the genral structure and provides necessary
data for the new reporting page designs.
Some of the data generated by the report domain classes (including
the mock CSP reporting class) was modified to fit new designs. This also
included removing data that was no longer necessary. Part of the newly
mocked data includes the idea of "expended" data per CLIN or task order.
This was was mocked simply by using a 75% of the obligated funds fo a
given object. Tests were also written for these new/ modifed reporting
functions.
As for the front end, this commit only focuses on the high-level markup
layout. This includes splitting the large reporting index page into
smaller component templates for each of the major sections of the report.
1. Funding duration
Returns a tuple of the earliest period of performance start date and
latest period of performance end date for all active task order in a portfolio.
2. Days to funding expiration
Returns the numbei of days between today and the lastest
period performance end date of all active task orders
3. Active task orders
Returns a list of a portfolio's active task orders a
This enables JSON logging for Celery workers if the LOG_JSON conig value
is set. It uses the same JsonFormatter class used by the Flask
applications. That class has been updated in two ways:
- It takes a `source` kwarg to define the log source for the formatter.
- The `msg` attribute of the log record is formatted with any arguments
that may have been passed. This is necessary for Celery to render task
type, completion time, etc. into the log output.
disabled env role
We were only checking to see if a role was disabled or deleted before
raising an error, so I added in a check to see if the user was trying to
update the env role before raising an error. The error should only be
raised if the role is disabled or deleted AND the user is trying to
assign a new role to the env role.
I also added in a disabled property to the EnvironmentRole model to make
things more readable.
A CRL test that relies on fixtures files was not getting a working copy
of the relevant CRL list it needed. This also adds a setup function to
the relevant test module so that we can clear and rebuild the CRL
location cache for the fixtures.
This change makes it so that when an env_role is updated to be None, the
role property on the env_role is changed to be None in addition to being
marked as deleted. This also adds in a check so that previously deleted
env_roles cannot be reassigned a role.
