Currently, we use both Python's built-in datetime library and Pendulum
to do datetime operations. For the sake of consistency, we should try to
stick to one library for datetimes. We could have used either, but
Pendulum has a more ergonomic API, so I decided to go with it when
possible.
The places where were we didn't / couldn't replace datetime are:
- checking instances of datetimes. Pendulum's objects are subclasses of
python native datetime objects, so it's still useful to import
datetime in those cases of using is_instance()
- WTForms date validators expect datetime style string formats --
Pendulum has its own format for formatting/ parsing strings. As such,
our custom validator DateRange needs to use datetime.stptime() to
account for this format.
Currently the create call will be consumed by on-demand requests from the frontend, and the 2 stage create will be used by the enviroment management group provisioning to verify an initial subscription was created.
In some functions, we redirect a user based on a parameter in a query
string. This commit adds a function that checks to see if a given url
matches a url pattern of a view function. This will help us ensure that
the url passed as the next parameter isn't malicious.
- Update the form to use BooleanFields for the permissions and make the
form more similar to the Application Members form
- Use MemberFormTemplate macro in the portfolio settings template
- fix tests affected by the form changes
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.
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.
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.
