Open nixocio opened 2 years ago
We commonly hit problems with performance when throwing the data needed into the global endpoint. The UI uses /api/v2/users/
for lots of sub-selection screens, like, adding a user to an organization, or giving that user permission to some single resource.
The notion that "a user is an execution environment admin" also doesn't really jive great with the API world view. Every organization has an EE admin role, and a user can have none or several of these granted to them. That fact doesn't seem worthy of putting in all user listings. To me, that sounds like a special-order request of the database, as opposed to a top-level model property.
I strongly agree that we should consolidate UI requests for the listed items. But if this is special purpose (like data needed on login), we already have special purpose endpoints like /api/v2/me/
Here's a really fast demo of the style of query I spitballed with @jakemcdermott .
[
[
(ContentType.objects.get(id=ret[0]).model if ret[0] else ret[0], ret[1])
for ret in Role.objects.order_by().filter(ancestors__in=u.roles.all()).values_list('content_type', 'role_field').distinct()
]
for u in User.objects.all()[:10]
]
I'll talk this out so that someone else could hypothetically run with it:
Role.objects
.order_by()
u
has direct or indirect access to .filter(ancestors__in=u.roles.all())
.values_list('content_type', 'role_field').distinct()
And that's it, simple as pie :smile: This gives all the fundamental role types that the user in question has. We can get textual summaries of these if desired (but the UI probably needs something easy to parse). So you want to ask the question:
Does the user have admin permission to any Notification Templates?
The answer is "yes" if the tuple ('organization', 'notification_admin_role')
appears in the list. Here's what an output typically looks like:
[('jobtemplate', 'admin_role'),
('jobtemplate', 'execute_role'),
('jobtemplate', 'read_role'),
('project', 'admin_role'),
('project', 'read_role'),
('project', 'update_role'),
('project', 'use_role'),
('credential', 'read_role'),
('credential', 'use_role'),
('inventory', 'adhoc_role'),
('inventory', 'admin_role'),
('inventory', 'read_role'),
('inventory', 'update_role'),
('inventory', 'use_role'),
('organization', 'admin_role'),
('organization', 'approval_role'),
('organization', 'credential_admin_role'),
('organization', 'execute_role'),
('organization', 'execution_environment_admin_role'),
('organization', 'inventory_admin_role'),
('organization', 'job_template_admin_role'),
('organization', 'member_role'),
('organization', 'notification_admin_role'),
('organization', 'project_admin_role'),
('organization', 'read_role'),
('organization', 'workflow_admin_role')],
This is fairly verbose because the org admin_role will trickle down to a lot of permissions. Nonetheless, there's an absolute maximum on how many entries will be returned, because there are only so-many role types in the system.
Acceptance criteria: Reduce number of api requests needed to load navbar by 50%
(Note: First, we'd need to identify the specific requests made to populate the navbar)
Assigning myself for API QE validation and @akus062381 for UI QE validation
ISSUE TYPE
SUMMARY
Reduce number of HTTP requests being made by the UI adding all data related to user profile data under one API endpoint. Right now, there are several requests being made as part of the Config context in order to know if the user is:
It would be ideal to provide all data about the user profile under one API endpoint, for instance, users.