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.
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.
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.
Replace ApplicationInvitations._update_status() with revoke() because multiple functions used _update_status() and it was causing app roles to be disabled when they shouldn't have. Now app roles are disabled within the revoke function.
Updated Invitations.resend() to accept user details so the invite info
can be changed in the new invite
There was a bug in the application settings route that threw an error if
an environment role and its associated application role did not have an
associated user. Updated to check for the user name on the application role.
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.
Use ApplicationRole.id instead of User.id in forms. This eliminates the
need for the function that checks whether a user is in a given
application, because looking up the application role will raise an error
if the user is not.
