Implementing workflow

  • Jean Jordaan

    Jean Jordaan - 2010-06-18

    We need to implement workflow in a Plomino application.

    - If UserA is ReponsibleStaff on ProjectX, then they should be able to fill in FieldB. (Otherwise, FieldB (or SubFormB) doesn't appear, or isn't editable).

    - If UserB belongs to the ManagingDivision on ProjectX and FieldB has been filled, then they should be able to submit it to the ProjectManager (UserC).

    - If UserC is ProjectManager on ProjectX, and it has been submitted to them, they should be able to submit it to the QADivision for verification, or to decline it (goes back to UserA to try again).

    - If UserC is ProjectManager, they should be able to delegate their right to submit/decline to UserD (who is Assistant to UserC).

    One way of building this may be to have documents for persons, divisions and projects, as well as documents for responsibilities. On a project, you have an action . This shows you a form to choose persons, and creates "responsibility" documents labeled ResponsibleStaff that each reference the project and the person. The ProjectManager works the same way. Similarly, you can have "responsibility" documents labeled Assistant that reference two persons.

    Another way of building may be to just have fields like ResponsibleStaff on Project that reference Person documents directly, or even store user ids. I think the previous way I sketched is more clear and general though.

    But I'm not sure where the workflow states and security should be implemented. Should there be State documents that reference all documents in that state? Or should documents just have a State field? Should there be a maze of hide-when sections around every field? Should fields be grouped into subforms for workflow-show-hide purposes? Should the formulas of all the individual fields (and sometimes documents) check their workflow state and whether the current user should be allowed to see them?

    Or would it be good to use e.g. to build workflows "next to" the Plomino app, and then let the Plomino app move "counter" or "placeholder" objects through the northstar workflow(s)?

  • Eric Brehault

    Eric Brehault - 2010-06-18


    use real Plone workflows (as uwosh.northstar offers) in Plomino is possible but will imply a lot of constraints
    because plone workflows manages permissions on entire objects (so on our Plomino documents)
    in Plomino, using forms and hide-when, we are in a more granular level: we can let a user edit such and such fields (via such or such forms which will only open in such an such conditions) whereas he cannot edit some other fields

    so basically permissions cannot be used

    of course we could consider using a workflow jsut to handle a state (and let the permissions unchanged), but in this case it is much simpler to handle the state into a Plomino field


  • Jean Jordaan

    Jean Jordaan - 2010-06-18

    > plone workflows manages permissions on entire object

    Yes, that's why I'm talking about Plomino managing placeholder objects moving through the workflow. So on a document, we'd check the state of our workflow-object next door in the northstar container. I think it would be very good to have the workflows visible in a tool like northstar, instead of having them implicit in a lot of Python snippets spread across many forms and fields.

    Do you have a best practice for doing workflows in Plomino? Or recommended examples?

  • Eric Brehault

    Eric Brehault - 2010-06-18

    yes we could manage it that way
    I have never tried (I always implement workflows directly into Plomino forms)


Log in to post a comment.