Loading...
 
Skip to main content

Comments

  • Louis-Philippe Huberdeau 03 Nov 10 20:54 UTC

    Transitions already have conditions called guards. Don't look at the tables, look at the libraries.

    Permission to trigger can also be applied to individual transitions.

  • gezza 03 Nov 10 23:09 UTC

    Hope you can give me some more, sorry if my questions are lame, I am coming form oracleDB & oracle forms & PL/SQL world, just exploring now the capabilites of mysql/php/smarty/javascript 😊

    Guard configuration:
    Can I configure guards from the frontend and assign them to a transition instance? if so than where are they stored and how are they linked? (by linked I mean how do you remember the relation between a transition instance and a guard instance)

    by configuration I also mean that as an end user I should be able to define from the frontend conditions (guards) with AND and OR relations that are to be evaluated before permitting the transition shift
    An example for a condition:
    (
    (is the user member of group A
    AND
    is the user from england
    AND
    is it the sysdate between 3-5 o'clock in the afternoon GMT 00:00 at time of the action
    )
    OR
    (
    does the user have permission item X
    )
    )

    If either all the 3 ANDs or the 1 OR is true, than the transition is allowed otherwise not.

    Guards can do this?

    Permissions:
    If I want to build up a controlled workflow from the frontend than I need to be able to assign permissions for each transition instance per workflow (= who can initiate a certain transition in that given workflow)

    Using the current structure this would trigger the need to be able to introduce a new permission on demand from the frontend per workflow profile, please correct me if I am wrong. (I guess this would create a big overhead which should be avoided)

    thanks for your feedback,
    cheers
    gezza

    •

      Louis-Philippe Huberdeau 04 Nov 10 00:52 UTC

      You can configure them from the transition UI (new in 6).

      Transitions work with both groups and categories, but individually. They don't mix.

      If you have a category transition, the guards will allow you to prevent the transition unless some condition is met. Conditions may be like "object also in category X", or "object not in category X", or "object in exactly 2 of X, Y, Z". You can assign multiple guards and they must all be met.

      Guards are stored in the transition table as a serialized block. That's why you need to go through the libraries to access them.

      There is no workflow concept. The workflow simply draws itself out from the multiple transitions included. The transition UI allows you to select a subset of states (categories or groups) and draw the diagram for you. Not quite documented though. Dropped that one apparently. It was in trunk before 5.0 was released.

      For a demonstration, you can apply the category transition demo profile.

      http://profiles.tiki.org/Category_Transition_DemonstrationQuestion

  • philippeback 10 Dec 10 07:52 UTC

    A good thing would be to write the details of the current state inside the module. Would be useful when there isn't any more transition to fire.

    I'll screenshot all that and post it.

Show PHP error messages