Introducing workflow status list in request's show page

[jeffibm]

Note: Using dummy data

Related PR-
NotificationMessage components issues have been solved here - #8894

[Fryguy]

Looks good for a start - let's get a live session going and we can collaborate on the design and details - not sure it should live on this page specifically, or perhaps it should replace the logging that David did.

[jeffibm]

Screen.Recording.2023-08-09.at.2.32.48.PM.mov

• Had listed the states.
• we are using the api/configuration_scripts/:id , but the id is hardcoded and the response is a dummy object for now.
• please see the 3 statuses. is this presentation ok?
• I haven’t implemented the refresh button, instead, the API will be called every 5 seconds and will update the list. is this ok?
• this keeps executing every 5 sec, when do we stop this?
• also, please have a look at the duration column. it has seconds and millieseconds. how do we want to print them?

[Fryguy]

This looks fantastic!

A few questions

• I presume this is only showing the provisioning workflow, because that's what's in the request? Do we need to potentially show other workflows?
• What happens on requests that aren't provisioning requests or that don't have workflows attached?
• I'm wondering if this makes more sense in the service page itself, similar to where the current embedded ansible output is (or perhaps both or perhaps a link from the request to the service) @agrare Thoughts here?

[noopurAg]

@Fryguy , these are the things implemented as per our initial discussions.. I have suggested using a refresh button instead of polling (for improved performance) to update the status dynamically .. Hope the design looks ok.
Here are the answers to your queries :

1. Yes , currently the workflow which is attached to the service will be shown post the service is ordered in the Request page .. The workflows per service will be shown , if there are multiple workflows attached (may be multiple catalog items or entrypoints) then we can show all the workflows attached to the service with the Status as Pending , Inprogress , Success and clicking on each workflow status we can show the details as per the states .. Need to get all the details from the API.
   For now @jeffibm has shown for 1workflow attached.

2.The request without provisioning worklfows attached will work as earlier i.e no information for the workflows status.. OR we can show the text displaying "No workflows attached".

3.If there is a place where we show ansible states that ll be good , we can show the worklfow status there itself instead of the request page , I was not aware so I have asked @jeffibm to include in the Request page itself .

[Fryguy]

Marking this PR as WIP until we remove all the dummy data and it's actually using proper API

[jeffibm]

Hey @Fryguy, from where can we extract the configuration_script_id that can be passed to the api.
the recordId passed into this component is the MiqRequest's id.

[Fryguy]

@jeffibm Merged ManageIQ/manageiq#22714 which should give you the id that you need.

[Fryguy]

As discussed we should drop the ConfigurationScript#${response.id}

[Fryguy]

Suggested change

	const name = response.name || response.description || `ConfigurationScript#${response.id}`;
	const name = response.name || response.description;

[Fryguy]

Not sure if another piece of code needs to change if name is null / undefined.

[Fryguy]

Reminder for us to come back to this in a follow up - we shouldn't need this.

[miq-bot]

Checked commits jeffbonson/manageiq-ui-classic@5fe3ef2~...6ab1930 with ruby 2.6.10, rubocop 1.28.2, haml-lint 0.35.0, and yamllint
2 files checked, 1 offense detected

app/views/miq_request/_st_prov_show.html.haml

• ⚠️ - Line 34 - Avoid using instance variables in partials views

[Fryguy]

LGTM - Also want @agrare approval before merge.

[agrare]

@DavidResende0 I'm not seeing the States in the MiqRequest details page anymore, confirmed I have a configuration_script_id in my MiqRequestTask#options
Does this work for you? Maybe I have something configured wrong

Nevermind I nuked my overrides while testing something else and forgot about it 🤦

[agrare]

LGTM

[Fryguy]

Backported to quinteros in commit bcf8c71.

commit bcf8c710e14cfc0159db1379f8521bf3eeda54ff
Author: Jason Frey <[email protected]>
Date:   Fri Sep 29 20:15:41 2023 -0400

    Merge pull request #8782 from jeffibm/workflow-status-list
    
    Introducing workflow status list in request's show page
    
    (cherry picked from commit cf29c3a96b578b48e11889c2fee5ad6beb539ad0)

[jeffibm]

I just tried running the specs locally and they are passing!!

Interesting, what do you see for edit[:new] in def entry_point_data when running that spec?

edit[:new] is always {:available_dialogs=>{}}, and type is always nil, but test cases seem to pass..

===================={:new=>{:available_dialogs=>{}}}
key= :fqname
fields = {:type=>:provision_entry_point_type, :configuration_script_id=>:provision_configuration_script_id, :previous=>:fqname_previous}
edit_new = {:available_dialogs=>{}}
type = nil
configuration_script_id = :provision_configuration_script_id

===================={:new=>{:available_dialogs=>{}}}
key= :reconfigure_fqname
fields = {:type=>:reconfigure_entry_point_type, :configuration_script_id=>:reconfigure_configuration_script_id, :previous=>:reconfigure_fqname_previous}
edit_new = {:available_dialogs=>{}}
type = nil
configuration_script_id = :reconfigure_configuration_script_id

===================={:new=>{:available_dialogs=>{}}}
key= :retire_fqname
fields = {:type=>:retire_entry_point_type, :configuration_script_id=>:retire_configuration_script_id, :previous=>:retire_fqname_previous}
edit_new = {:available_dialogs=>{}}
type = nil
configuration_script_id = :retire_configuration_script_id

.===================={:new=>{:available_dialogs=>{}}}
key= :fqname
fields = {:type=>:provision_entry_point_type, :configuration_script_id=>:provision_configuration_script_id, :previous=>:fqname_previous}
edit_new = {:available_dialogs=>{}}
type = nil
configuration_script_id = :provision_configuration_script_id

===================={:new=>{:available_dialogs=>{}}}
key= :reconfigure_fqname
fields = {:type=>:reconfigure_entry_point_type, :configuration_script_id=>:reconfigure_configuration_script_id, :previous=>:reconfigure_fqname_previous}
edit_new = {:available_dialogs=>{}}
type = nil
configuration_script_id = :reconfigure_configuration_script_id

===================={:new=>{:available_dialogs=>{}}}
key= :retire_fqname
fields = {:type=>:retire_entry_point_type, :configuration_script_id=>:retire_configuration_script_id, :previous=>:retire_fqname_previous}
edit_new = {:available_dialogs=>{}}
type = nil
configuration_script_id = :retire_configuration_script_id
.

Finished in 1.9 seconds (files took 5.32 seconds to load)
2 examples, 0 failures

I tried adding the value for type,
assign(:edit, :new => {:available_dialogs => {}, :retire_entry_point_type => 'embedded_automate', :reconfigure_entry_point_type => 'embedded_automate', :provision_entry_point_type => 'embedded_automate'})

[agrare]

@jeffibm okay so what do you see when you hit this line? https://github.com/ManageIQ/manageiq-ui-classic/pull/8928/files#diff-fe38c2f9cecf78cbae1c519ca7881982dbf556e342a3f04e732b7c17eecdaab2L13

[jeffibm]

@jeffibm okay so what do you see when you hit this line? https://github.com/ManageIQ/manageiq-ui-classic/pull/8928/files#diff-fe38c2f9cecf78cbae1c519ca7881982dbf556e342a3f04e732b7c17eecdaab2L13

when bundle exec rspec spec/views/catalog/_form_basic_info.html.haml_spec.rb
type = nil inside _provision_entry_point.html.haml#line13
2 examples, 0 failures

[agrare]

If type is nil then I don't know how this wouldn't have failed for you previously 🤷