Bug 1589261

Summary: [RFE] Provider operations with playbooks - pluggable UI for button that can be defined by provider dev and lives with the provider repo
Product: Red Hat CloudForms Management Engine Reporter: Gregg Tanzillo <gtanzill>
Component: ProvidersAssignee: Martin Povolny <mpovolny>
Status: CLOSED ERRATA QA Contact: Nikhil Dhandre <ndhandre>
Severity: high Docs Contact:
Priority: high    
Version: 5.10.0CC: gblomqui, jfrey, jhardy, mpovolny, obarenbo, simaishi, smallamp
Target Milestone: MVPKeywords: FutureFeature
Target Release: 5.10.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 5.10.0.11 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-02-07 23:03:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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