MPP User Actions Logic

[doubando]

MPP Actions should contins a Logic to determine what Acitons should be displayed.

Example: Server Status is "Online" or "Active" the action associated with that should be "Stop" , and "Start" Action should be dimmed out or not displayed and vice versa if the Server Status is "OFF" or "Shutdown" the Action menu should contains only "Start Action".  and "Stop" Action should be dimmed out or not displayed

Currentely CSA MPP displaying both Actions regarless of the server status the logic should be build based on component attribute like "Status" and based on status specific action groups should be displayed.

hope to consider this

[Ahmed_Mahmoud]

it is a amazing idea that should be considered

[AHMEDEZZAT2019]

Hopefully they implement that very soon, it is required in our Market Place Portal as well

[Dondon22]

This is what good Engineers do... make suggestions to improve the product to be more appealing to the needs of its target market 🙂

So... Kudos to you @doubando 🙂

[M_Elkowayies]

it's brilliant idea , i hope MicroFocus do it ASAP

[Michael_it]

This is possible as of today by using the legacy API (basically since csa 3 as far as i remember). you can manipluate visiblity of lifecycle actions or completely add/remove lifecycle actions on demand. we are doing this as of today for exactly the stop/start delete snapshot scenarions. never the less an easier inbuild function would be appreciated.

to do it today: in the flow that updates your state you must update the resource subscription

get on

${CSA_REST_URI}/artifact/${RSC_SUBSCRIPTION_ID}?userIdentifier=${userIdentifier}&scope=view&view=actioninfo

XSLT the visibility as you need

PUT back to ${CSA_REST_URI}/artifact/${RSC_SUBSCRIPTION_ID}?userIdentifier=${userIdentifier}&scope=view&view=actioninfo&_action_=merge

[nivghosh]

Thanks @Michael_it  for sharing the current mechanism that can be used to hide/show actions based on run time "state".  I am curious if others have seen this post and what is their comment about this current approach.

While I agree that if the system gives a way to do this automatically that would be less work for customers, but we also have to consider that an "action" can do "anything", the system has no idea what is the purpose of an action and any "context"  or semantic meaning of the action either. The specific example stated here makes it sound like a very simple thing to do where an action can be naturally correlated to the "state" of a server, however, that's just about this action and we need to build the system w/o making any assumption of what the action does in particular. In order to acheieve that, we will then need to provide an interface where one action can define whch other action is complementary to each other. It just would introduce another level of configuration which would be used not so frequently. Hence my question: given that we have a programmatic interface to hide/show "any" action, couldn't the service implementer add the logic to hide the corresponding complemetary action at the last step of action logic? Is that too much of a burden for the service implementer while we do not add complexity into action configuration and for the fact this provides flexibility to the service implementer?

Now, I will acknowledge that we did not do a good job of showcasing this technique in our own content that we provide, if was had done that, I believe many customers would have found that approach reasonable and would have followed in their own service impelementation.

Regards,

Nivedita

[Michael_it]

i understand the concerns around to many possible solution ways and allowing most flexibility here.

i would at least see some Helper Flows similar to "get artificat properties" in OO CSA Integration CP that allow hiding yes/no of actions and potentially also deleting/adding actions on the Fly.

specifically adding actions was cumbersome as you manually have to construct the XML.

never the less this always combined with an extra flow logic. also means that you always have to run a flow. that needs to understand when to turn off/on actions.

The advatage of source binding the visibility of an action to a boolean property (potentialy with negation sign !) of a component is that you dont need to care how many actions are depending on this state. you can just change the state via API even from a external System.

this would make it easier for different people.

but from my PoV there are much more other features needed where we have no solution/workaround so this Feature would have low priority as we have a solution.