Add several changes to API and UI related to Instance Groups.
* Update summary_fields for DEFAULT_CONTROL_PLANE_QUEUE_NAME, and
DEFAULT_EXECUTION_QUEUE_NAME. Rely on API validation for those fields.
* Fix Instance Group list RBAC
* Add validation for a couple of fields on the Instance Groups endpoint
1. is_container_group
2. policy_instance_percentage
3. policy_instance_list
See: https://github.com/ansible/awx/issues/11130
Also: https://github.com/ansible/awx/issues/11718
keep pre-upgrade events in an old table (instead of a partition)
- instead of creating a default partition, keep all events in special
"unpartitioned" tables
- track these tables via distinct proxy=true models
- when generating the queryset for a UnifiedJob's events, look at the
creation date of the job; if it's before the date of the migration,
query on the old unpartitioned table, otherwise use the more modern table
that provides auto-partitioning
- Organization.default_environment
- Project.default_environment
- JobTemplate.execution_environment
- WorkflowJobTemplate.execution_environment
System jobs are not editable by anyone other than a system admin, so
we don't need to check. It appears that unified job templates can't
be created or edited outside of the endpoints for the specific types.
can_add: gets an explicit role to check against, `'execution_environment_admin_role'`
can_change: leverages `self.check_related()` for the case where the Org is not changing, but also adds an explicit check for the EE Admin Role when the Org is changing to an explicit different Org.
- a new unique name field to EE
- a new configure-Tower-in-Tower setting DEFAULT_EXECUTION_ENVIRONMENT
- an Org-level execution_environment_admin_role
- a default_environment field on Project
- a new Container Registry credential type
- order EEs by reverse of the created timestamp
- a method to resolve which EE to use on jobs
Fixed bug where an org admin was not able to add
an orphaned user to the org, in the case where the
orphan had an ancestor role that matched one of the
roles for of the org admin.
scenario to fix -- sue is member of cred1, where cred1 is
part of org1. org1 admin cannot add sue to org1, because
the cred1 role for sue has an ancestor to org1 role. The org1
admin cannot change or attach sue to org1.
tower issue #4198 and #4197
Set JT.organization with value from its project
Remove validation requiring JT.organization
Undo some of the additional org definitions in tests
Revert some tests no longer needed for feature
exclude workflow approvals from unified organization field
revert awxkit changes for providing organization
Roll back additional JT creation permission requirement
Fix up more issues by persisting organization field when project is removed
Restrict project org editing, logging, and testing
Grant removed inventory org admin permissions in migration
Add special validate_unique for job templates
this deals with enforcing name-organization uniqueness
Add back in special message where config is unknown
when receiving 403 on job relaunch
Fix logical and performance bugs with data migration
within JT.inventory.organization make-permission-explicit migration
remove nested loops so we do .iterator() on JT queryset
in reverse migration, carefully remove execute role on JT
held by org admins of inventory organization,
as well as the execute_role holders
Use current state of Role model in logic, with 1 notable exception
that is used to filter on ancestors
the ancestor and descentent relationship in the migration model
is not reliable
output of this is saved as an integer list to avoid future
compatibility errors
make the parents rebuilding logic skip over irrelevant models
this is the largest performance gain for small resource numbers
This is the old version of this feature from 2019
this allows setting the organization in the data sent
to the API when creating a JT, and exposes the field
in the UI as well
Subsequent commit changes the field from editable
to read-only, but as of this commit, the machinery
is not hooked up to infer it from project
a side effect of this bug is that `awx schedules create` doesn't work
properly for non-admin users (i.e., users who have execute access for
a JT)
see: https://github.com/ansible/awx/issues/5717
* RBAC relaunch 403 updates
Addresses 2 things
1. If WFJ relaunch is attempted, and relaunch is denied
because the WFJ had encrypted survey answers,
a generic message was shown, this changes it to show
a specific error message
2. Org admins are banned from relaunching a job
if the job has encrypted survey answers
* update tests to raises access pattern
* catch PermissionDenied for user_capabilities
