Bug 1648819 - When ordering a service via the API the service dialog is not executed
Summary: When ordering a service via the API the service dialog is not executed
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: API
Version: 5.9.6
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: GA
: 5.9.6
Assignee: Tina Fitzgerald
QA Contact: Parthvi Vala
Red Hat CloudForms Documentation
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-12 08:16 UTC by Parthvi Vala
Modified: 2018-11-20 15:01 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1635673
Environment:
Last Closed: 2018-11-20 07:46:46 UTC
Category: ---
Cloudforms Team: CFME Core
Target Upstream Version:


Attachments (Terms of Use)

Description Parthvi Vala 2018-11-12 08:16:59 UTC
Description of problem:
When ordering a service from the service catalog via the API, none of the defaults defined in the catalog item's service dialog are applied and no dynamic dialog elements are executed.  This used to work in previous versions of CFME.

Version-Release number of selected component (if applicable):
5.9.6

How reproducible:
100%

Steps to Reproduce:
1. Create a service dialog
2. Add at least one static element that has a default 
2. Add one dynamic element that executes a method to return a default
3. Order the service via the API

Actual results:
1. When monitoring the automation.log you see that the dynamic element does not execute the method.
2. Nothing is set in $evm.root['dialog_<var>'] from the dynamic element
3. Nothing is set in $evm.root['dialog_<var>'] from the static element default

Expected results:
1. Dynamic elements should run the specified method when the service is ordered and the default set by the method should be passed to $evm.root['dialog_<var>']
2. Static elements should pass the default set in the service dialog to $evm.root['dialog_<var>']

Additional info:
This is duplicate of bug: https://bugzilla.redhat.com/show_bug.cgi?id=1639413

Comment 3 Tina Fitzgerald 2018-11-12 16:21:39 UTC
Hi Parthvi,

Comment 22 in the original ticket states that a configuration change is required to resolve this issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1635673#c22

The reproducer steps above do not mention the configuration changes.
Can you supply a reproducer environment for this issue?

Thanks,
Tina

Comment 4 Parthvi Vala 2018-11-13 05:24:15 UTC
Hi Tina,

I had a talk with Drew about the same thing. I applied the patch and got the expected response. But things were working fine even without applying patch on 5.9.5.3, since the patch was already applied to it. Shouldn't the patch be included for 5.9.6 as well?

Thanks,
Parthvi

Comment 5 Tina Fitzgerald 2018-11-13 21:24:05 UTC
Hi Parthvi,

Yes, since the code change was included in 5.9.5.3, 5.9.6 should work as well,
unless another code change broke that functionality.

Could you please supply a reproducer environment?

Thanks,
Tina

Comment 7 Tina Fitzgerald 2018-11-14 16:32:43 UTC
Hi Parthvi,

As
https://bugzilla.redhat.com/show_bug.cgi?id=1635673#c26 states, the configuration setting necessary for this change to work, is to set to false in the specified appliance advanced setting.

 :run_automate_methods_on_service_api_submit: false

Please change the setting and retest.

Comment 10 Parthvi Vala 2018-11-20 07:46:46 UTC
Hi John,

This is not a bug, I hadn't applied the required changes to the env which caused the issue. I am now closing the BZ.

Thanks,
Parthvi


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