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.
I guess the sqlite adaptation of the JSONField was resulting in a json
encoded blob, where as the postgres version returned something that got
parsed out normally with the rest of the query result?
Having this in here causes us to go out and pull down the repo whenever
we run a test, adds around 9 seconds per test on a good connection.. if
we need real data in here, we should figure out how to get it locally
This prefetching gets really expensive when we have a large number of
hosts, it's far less expensive to just go out and do subsequent queries
to pull this data in. (dropped aggregate query time down from ~2400ms to
~180ms)
Now we can stuff some more data in this table so we can take advantage
of some multi-column indexing and avoid another to join for our
accessible objects and permissions queries.
Akita Noek