CSA UI - separate form for subscription order and subscription modification

Idea ID 1641133

CSA UI - separate form for subscription order and subscription modification


Now we have one user form for subscription order and subscription modification. The only things we can do is to hide some Option Sets during modification process ( un-modifiable Option Sets). It is not very convenient.

Firstly, even if they are hidden, un-modifiable Option Sets still exists during modification process. And dynamic lists are still building. And, if some dynamic list changes, and older value, that was set during order phase, may not belong to the list any more. Let me give you an example:

OS list is a dynamic list, containing all suported OS. User orders subscription with OS "Windows Server 2008". After a year company deside not to deoloy Win 2008 any more - but in old subscription we still have old value. Because of that, this older subscription can not be changed without manipulation - we should write new dynamic list script, and re-publish all services with new dynamic list version. 

Seconldy, I may want to add some new Option Set during modification, connected only with modification, with no pricing connected with it. For example, to choose, is it allowed to reboot server during modification (in the order phase, this option have no sence).

Finally, I sometimes do not want to show particular fields in Option Sets during modification phase. For example, you can choose disk mount point only once -  and shouldn't be able to modify it, but you SHOULD be able to modify disk size.

To sum up, I want to have a different order and modification forms. Of course, they should have common option sets to deal with pricing, but they should also have non-intersections Option sets. And I want an opportunity to hide specific fields during modification process.

Not applicable
Vice Admiral
Vice Admiral

for first problem we had a bug case and lengthy discussion around.

what should be introduced (like with the validationscripts in CSA 4.8) is an old value input to the JS/JSP that will give you the oportunity to evaluate if you show back in JSP the old value or not

also we discussed if hidden JSPS /not modified JSPS should be evaluated at all... we think there are scenarios where hidden JSPS should be evaluated. but order should not fail when field is not required (which is currently no opttion for jsp lists ... having empty list)

on your second requests. this we posted already under old ER process .... that we need also optionsets for Modify Only ... so not visible in Order

your final point is achievable today. .... you will just need to split accross optionset or hierachy of optionssets.. we do this today.

eg. toplevel Optio (not modifiable) contains inputs Mountpoint, Storage quality. sublevel optionset. "additional Disks" as multiselect (modifiable) with Disk sice


so ill vote for the Idea mainly to get the Second point you mentioned in.

i am not sure if it will be possible to implement as suggested with intersecting/nonintersection sets or rather better Hidding logic. ill leave this up to R&D.

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.