Return property method actions on Generic Object subresources #247
Conversation
|
@miq-bot assign @imtayadeway |
| @@ -352,7 +352,7 @@ def add_actions(json, aspecs, type) | |||
| def expand_resource_custom_actions(resource, json, type, physical_attrs) | |||
| return unless render_actions(physical_attrs) && collection_config.custom_actions?(type) | |||
|
|
|||
| href = json.attributes!["href"] | |||
| href = @req.subcollection.present? ? collection_href(@req.subcollection, resource.id) : json.attributes!["href"] | |||
There was a problem hiding this comment.
/cc @imtayadeway I think collection_href is gone with 866c813
There was a problem hiding this comment.
Is this important? What's written there is wanting to force accessing the custom action urls in the top level collection when we just went the opposite direction in that we've 'fixed' things to prefer being nested if at all possible. So I'm wondering from a business perspective if that can/should be nested and I'll just change that here.
…sub collection by moving more methods into the shared generic objects mixin Resolves https://bugzilla.redhat.com/show_bug.cgi?id=1518803
…tion href should be returned because custom actions are not supported on sub resources.
To fix hrefs in base controller abstraction land that doesn't have concrete controllers/serializers for exceptions, we've 'normalized' hrefs the best we could by deterministically giving an href based on the request that prefers to be nested when possible - but are now screwed because it's actually determined by what you can and can't do with nested collections in the interface. So, this does the same sort of hacky override that was here, just without the misleading helper that was present before by constructing our own URL deliberately.
568fd68 to
eaec60d
Compare
🙃 |
|
LGTM!! 👍 will merge when 🍏 |
|
Checked commits jntullo/manageiq-api@ca8449b~...eaec60d with ruby 2.3.3, rubocop 0.47.1, haml-lint 0.20.0, and yamllint 1.10.0 |
Return property method actions on Generic Object subresources (cherry picked from commit 78fc3b6) Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1530714
|
Gaprindashvili backport details: |
Currently when retrieving a generic object subresource, ie:
The custom actions / property method actions are not being returned. This change moves code from the generic objects controller into the shared generic objects mixin so that the actions are returned as they should be.
This also fixes another issue where the href being returned for custom actions specifies the subresource href, ie
POST /api/generic_object_definitions/:c_id/generic_objects/:id. This is incorrect, because when attempting to call the custom method with this href, it results in:when attempting to call this action. Generic Objects were not the only resource affected by this problem.
@miq-bot add_label blocker, bug, gaprindashvili/yes
Resolves https://bugzilla.redhat.com/show_bug.cgi?id=1518803