6 Commits

Author SHA1 Message Date
Philip Kalinsky
69bd2f43a5 provision portfolio state machine 2020-01-14 16:36:16 -05:00
dandds
7010bdb09c Record job failures with application context.
AT-AT needs to be able to track which user tasks failed and why. To
accomplish this we:

- Enabled Celery's results backend, which logs task results to a data
  store; a Postgres table, in our case.
  (https://docs.celeryproject.org/en/latest/userguide/tasks.html#result-backends)
- Created tables to track the relationships between the relevant models
  (Environment, EnvironmentRole) and their task failures.
- Added an `on_failure` hook that tasks can use. The hook will add
  records to the job failure tables.

Now a resource like an `Environment` has access to it task failures
through the corresponding failure table.

Notes:
- It might prove useful to use a real foreign key to the Celery results
  table eventually. I did not do it here because it requires that we
  explicitly store the Celery results table schema as a migration and
  add a model for it. In the current implementation, AT-AT can be
  agnostic about where the results live.
- We store the task results indefinitely, so it is important to specify
  tasks for which we do not care about the results (like `send_mail`)
  via the `ignore_result` kwarg.
2019-09-09 14:54:46 -04:00
dandds
c4ad7b4378 Make portfolio invitation specific to portfolio
- 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"
2019-04-30 14:41:55 -04:00
dandds
0bde431a70 extend soft delete functionality to app and env roles 2019-04-15 15:58:38 -04:00
dandds
bec5d11bfe users have permission sets for site-wide perms 2019-03-21 05:38:28 -04:00
richard-dds
ddc2e2fad7 Automatic audit logging using SQLA events 2018-09-25 13:09:54 -04:00