[WB] After changing the type of wf its structure also has to change

Bug #1436409 reported by Anastasia Kuznetsova on 2015-03-25
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Merlin
High
Timur Sufiev

Bug Description

There are two types of workflows: direct and reverse in Mistral. These types have a little bit different wf structure and different set of options, for example: direct wf has 'on-success'/'on-error'/'on-complete' option in the 'task-defaults' section in opposition to reverse wf.
It means that after choosing another wf type in the form, wf structure has to change on the fly.

Timur Sufiev (tsufiev-x) on 2015-04-20
Changed in merlin:
importance: Undecided → Medium
status: New → In Progress
assignee: nobody → Timur Sufiev (tsufiev-x)
Timur Sufiev (tsufiev-x) on 2015-04-20
summary: - [Workbook builder] After changing the type of wf its structure also has
- to change
+ [WB] After changing the type of wf its structure also has to change
Timur Sufiev (tsufiev-x) on 2015-04-20
Changed in merlin:
importance: Medium → Critical
importance: Critical → High

Reviewed: https://review.openstack.org/170206
Committed: https://git.openstack.org/cgit/stackforge/merlin/commit/?id=5014b8de587947e2019f081d5b2b17e5c14c2af1
Submitter: Jenkins
Branch: master

commit 5014b8de587947e2019f081d5b2b17e5c14c2af1
Author: Timur Sufiev <email address hidden>
Date: Thu Apr 2 19:41:44 2015 +0300

    Enable the Workflow structure change on changing its type

    To enable this fix, a massive refactoring to panel/row/item - i.e.,
    the 'view' mixins - was done. Now these mixins are implemented as
    filters, which has the following benefits:
     * once the underlying Barricade model changes, the following change is
     immediately propagated to the view (input events are no longer
     catched by some obsolete piece of model just because view is not
     updated and is still sending events to an old model);
     * at the same time the filter results are memoized (with the
     appropriate function from underscore.js) so not infinite $digest
     looping happens, with the Barricade objects' string hash being used
     as a parts of a composite caching key.

    Also change .toJSON() usage in Mistral models to .toJSON({pretty: true})
    usage to not interfere with deserializing JSON blobs when we need to
    recreate a Barricade object from JSON blob.

    Provide a foundation of a suite of filters unit-tests - just a list of
    specs being verified with an actual code to be written later.

    Closes-Bug: #1436409
    Change-Id: I7af36abbdcfab70a6b867c39e49420d1716c1310

Changed in merlin:
status: In Progress → Fix Committed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers