This patch covers all the cases I could find of places where you could
delete items that you are currently editing. When this happens, we
should now exit the edit mode and return to the list view for whatever
we were viewing.
Related to #1742
Addresses the most important part of #1742 , next patch will be to make
it so we just navigate away from the detail page if we delete the item
we're on.
This is really to fix#1445, the problem being that "" does not pass
float validity, and the show/hide was triggering a check which included
the hidden-but-still-there float fields. So this is an easy work around,
and I think it's better UX as well since these values are required to be
filled in in many cases.
Fix survey maker add button after toggling password visibility
* Fixed column width to 50% for both job stdout view and inventory update
script output view
* Fixed scrolling behavior so we don't have two elements doing scrolling
(inner was doing width, outter was doing height)
* Reduced max height for stdout jt output view to 900px down from
1600px
* Flexified inner output window on inventory script output view so the
gray output area always fills the height of the panel
#2127 @2028
* 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.
Akita Noek