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.
For name and description, we'll derive these from the role_field and
content type, which is much better for lots of reasons (eg changing text
the future). Also ditched the rest of the fields comming from the
standard common base model, we didn't use them and they cost several
indexes on the table.
We removed the actual need for this when we broke the org<->team cycle.
This patch removes the code we had to support that, but since it's
costly and unused, it's now nixxed.
Akita Noek