* Appropriately set project and playbook to default when job type is set
to 'scan' - #1273
* Add 'RESET' link on the Project label line to reset to Default
project/playbook #858
* Fixed dropdown option clearing problem #1489
* Remember what project/playbook was set when switching from run/check
to scan, so if you change back, those options will be auto-selected
again
Having this triggers a license feature test, which the jenkins test
system apparently doesn't have.. I don't think it's particularly
important to test this particular field, so meh.
This addresses #1981 which says that JT admins can make modifications to
a job template freely if they're just changing non functional things
like name, description, forks, verbosity, etc, while requiring them to
have access to all functional components if they're going to make any
changes to the functionality - in specific, any changes to the
inventory, project, playbook, or credentials requires that the user have
the appropriate use access on all of those things in order to make the
change.
This mostly reverts 3c67971e78a12bd94536aa5464f0bc1ea46ba1ee with
the minor difference that we only apply this when we're filtering,
which is apparently necessary without some notable overhaul since
the filtering we're doing will get stuck in as filters, which will
generate inner joins, which can result in duplicates if the thing
we're joining with is a one to many or many to many, which most
things are.
With this patch we still need to be generating naturally distinct
querysets with any `get_queryset` methods, which will still be much
more effecient when filtering is not involved.
This fixes#2032 and probably a bunch of other undiscovered issues.
This code was fine for the 0009 migrations since we introduced all roles
at once, however with changes in 0017 we can't just patch from the
roots, so this works generically without having to get fancy about
identifying which roles we need to actually update.
As per a UI request, we don't want to show the implicitly defined
'admin_role' roles that get created for every user so they can manage
themselves. These roles exist for every user, and the only members of
those roles are the users themselves, so it's a pretty boring role. We
also don't want to allow for anyone to be removed from their own admin
role, so hiding this is probably a good thing all around to avoid
confusion and clutter.
Fixes#1689
can_update is a special model getter that checks to see if the project
is in a valid state it looks like - so it's important to check this for
superusers too. The can_change check does the implicit is_superuser
check for us, so we don't need another expclit check here, just
can_start protection.
In old_access.py we restricted even super users from doing this. I'm not
sure that it'd actually break anything to allow this, but I'm making the
new access.py behave like old_access.py for good measure until we have a
valid usecase for this.
as it should have always been. This messes up being able to post to
api/v1/users/:n/credentials and api/v1/teams/:n/credentials without
specifyign the user/team id in the post body, but looking at the old
code it looks like this might have always been the case, so whatevs..
This fixes a old v new access.py test "failure", and is better anyways..
This test was passing before because we were erroneously making all
users organization auditors, which gave users read access to all JT's
under the org.
This step ensures all of our roles get setup before we start the
migration. It also speeds things up a little as we can wrap everything
with a `with batch_role_ancestor_rebuilding()`. We were pretty much
doing this already, but we had an issue where we didn't catch all job
templates all the time, so this just makes it very explicit and ensures
everything is setup, and does so a little faster.
Switched to using pre_delete instead of post_delete to record activity
stream delete operations so we have access to all of the fields that may
be associated with the field (eg things that may be being deleted with
this object through a cascade delete).
Switched to recording the full dict of the object instead of a diff
(since the diff will always be empty).
This .distinct() call applied .distinct() to all list query sets. Most
query sets are already unique, and adding .distinct causes the database
to do a lot of extra work. Views that rely on this behavior will be
rooted out during the hardening sprint and .distinct() will be added to
the individual querysets as needed instead of applying this everywhere.
Akita Noek