Bug 1589261 - [RFE] Provider operations with playbooks - pluggable UI for button that can be defined by provider dev and lives with the provider repo
Summary: [RFE] Provider operations with playbooks - pluggable UI for button that can b...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Providers
Version: 5.10.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: MVP
: 5.10.0
Assignee: Martin Povolny
QA Contact: Nikhil Dhandre
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-06-08 14:35 UTC by Gregg Tanzillo
Modified: 2019-02-07 23:03 UTC (History)
7 users (show)

Fixed In Version: 5.10.0.11
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-07 23:03:07 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:0212 0 None None None 2019-02-07 23:03:23 UTC

Description Gregg Tanzillo 2018-06-08 14:35:13 UTC
Description of problem:

Buttons supporting provider operations should have the ability to be developed independently by a provider developer. The button definitions should live in the provider repo with the rest of the provider code.

Some of the things we'll need -
a. Overridable buttons and button groups
b. Button routing 
c. Dialogs
    1. Static dialog via ruby
    2. React.js for dynamic
d. Loop through plugins (provider repos) and pull in buttons and button groups
e. Pluggable product features for buttons

Comment 4 Martin Povolny 2018-08-08 13:04:04 UTC
a, b, c2, d are done.

c1 is an opened PR being tested and reviewed today.

No one is working on e) and from what I understood it's not going to be implemented for Hammer. I'll refer to my backend/core colleagues with that part.

Comment 5 Gregg Tanzillo 2018-08-08 18:09:38 UTC
I think we're in very good shape with this one. The 2 outstanding items would not block us if we don't get them finished

For c. Dialogs, 1. Static dialog via ruby
I’m not sure how important that one is. It seems like the purpose of this effort is so that provider developers won’t have to write ruby code for their dialogs. So I think that one is not too important.

And for e. Pluggable product features for buttons
The pluggable product features is more like a bonus item to me because most cases would be covered by an existing feature. And the case where a new one is needed could be handled as a one off.

If we don't get these in by the end of the dev cycle we can create new BZs for them if we decide we still need them

Comment 8 Nikhil Dhandre 2018-10-08 05:49:42 UTC
As per Martin comment and my gitter discussion with Miha(Xlab). I understand this feature; I need to push some methods on provider side ManageIQ repo which is not a good idea. This feature is for developers not for direct customers. This awesome react component feature help to modify UI for the respective provider.

This feature must be test and use by provider developers for their development not by QE.

Comment 10 errata-xmlrpc 2019-02-07 23:03:07 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:0212


Note You need to log in before you can comment on or make changes to this bug.