Repository navigation
Conversation
| :klass: AutomationRequest | ||
| :subcollections: | ||
| - :request_tasks | ||
| - :request_logs |
There was a problem hiding this comment.
OH, we added @Fryguy as a test
1) API configuration (config/api.yml) collections is sorted a-z
Failure/Error: expect(actual).to eq(expected)
expected: [:accounts, :actions, :alert_actions, :alert_definition_profiles, :alert_definitions, :alerts, :auth,...mplates, :tenant_groups, :tenants, :time_profiles, :users, :vms, :volume_mappings, :widgets, :zones]
got: [:accounts, :actions, :alert_actions, :alert_definition_profiles, :alert_definitions, :alerts, :auth,...mplates, :tenant_groups, :tenants, :time_profiles, :users, :vms, :volume_mappings, :widgets, :zones]
(compared using ==)
Diff:
@@ -106,8 +106,8 @@
:rates,
:regions,
:reports,
- :request_logs,
:request_tasks,
+ :request_logs,
:requests,
:resource_actions,
:resource_pools,
# ./spec/lib/api/api_config_spec.rb:10:in `block (3 levels) in <top (required)>'
There was a problem hiding this comment.
ugh, I fixed the one but not the other, one second...
| :subcollection_actions: | ||
| :get: | ||
| - :name: read | ||
| :identifier: miq_request_show |
There was a problem hiding this comment.
I need to double check what the classic UI and (if the service UI has it, which it might not) uses in order to determine who can see request logs... the current logic is to show request logs for people who can see the request.
There was a problem hiding this comment.
will change this to miq_request_show_logs, which is what the UI uses. Service UI doesn't seem to have this at all so if it adds it, it can also use this same feature or add it's own.
38c6975 to
595101f
Compare
jrafanie
changed the title
|
@prashantsrivastava6, can you give this a try and report any results? I changed the product feature to use |
|
@Fryguy do you want to get this in, I think it's all ready to go? We can get feedback when it lands. |
Request logs are recorded for every MiqRequest (e.g. approval and automate events) but could not be retrieved through the API, so clients had no way to see why a request was stalled or failed. Authorize with the existing miq_request_show_logs product feature, the same one the classic UI checks before rendering the Request Logs section, so the API and UI agree on who can see request logs. This matters for custom roles that were granted miq_request_show without the Logs feature. The parent MiqRequest lookup is already RBAC-filtered before request_logs_query_resource runs, so scoping by resource_id is enough. Added to requests, service_requests, provision_requests and automation_requests for consistency with request_tasks.
595101f to
84b32b8
Compare
|
Now, it's ready for review |
|
Checked commit jrafanie@84b32b8 with ruby 3.3.12, rubocop 1.91.0, haml-lint 0.78.0, and yamllint 1.37.1 |
Request logs are recorded for every MiqRequest (e.g. approval and
automate events) but could not be retrieved through the API, so clients
had no way to see why a request was stalled or failed.
Authorize with the existing miq_request_show_logs product feature, the
same one the classic UI checks before rendering the Request Logs
section, so the API and UI agree on who can see request logs. This
matters for custom roles that were granted miq_request_show without the
Logs feature.
The parent MiqRequest lookup is already RBAC-filtered before
request_logs_query_resource runs, so scoping by resource_id is enough.
Added to requests, service_requests, provision_requests and
automation_requests for consistency with request_tasks.