* Fixing some bugs in the manifest definition
* Database model and schema migration for tower settings
* Initial View and Serializer implementation using a strategy of merging
model instances and named tuples
* Settings manifest, mapping internal settings to what can be used in
the database along with type information etc.
* Initial Database model
* Helper object that overlays database settings on django settings
If a social auth user is deleted and then attemnpts to relogin after the
old user object has been removed then it can cause an error. So here
we'll add an extra lookup for the user just to verify
* Move auth backends into sso app.
* Add support for mapping social auth users into organizations and teams.
* Return social auth backends in a consistent order in the API.
* Remove custom SAML attribute mapping and use options provided by PSA.
* Add pipeline function to raise an exception if no user has been found or created; added comments on how to disable new user creation.
* Add comments for defining a custom social auth pipeline function.
* Fix an issue I created overriding authenticate
* Fix up attribute mapping using an identity provider class. The
methods built into django-social-auth for saml are probably not going
to work. We also now expose those mappings in a settings attrs map
that the user can override.
* Initialize object attribute to None so a later if check that depends
on that attributes succeeds. The attribute is related to unifying the
command line args to the *_instance command set.
* Added regression test case
* Abstract authention to provide a hook for emitting an error message
* Perform some license validation that wasn't present before for
enterprise licenses
Originally we were looking at the underlying project/inventory update
but we are now populating the name of project updates and inventory
updates a lot better so we'll just take their names
Slight tweak to the rbac for projects related to the user who created
them. IF a user created a project but it is orphaned/not associated
with an organization then they will be able to see/change it. If,
however, it is created and associated with an organization and then they
are removed as an org admin they will no longer have access to it.
Now, simply being the creator of a project does not convey any access
for users. You must be in a project/team that has access to it and you
must be an org admin for an org that has the project to be able to make
changes to it
If the extra var PEXPECT_SLEEP is given to a job then it will
artificially delay the job run by that number of seconds allowing QA to
hook in and cancel the job
