Uploaded image for project: 'iDempiere'
  1. IDEMPIERE-3599

allow DocActions to be selected in a more flexible way

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Sprint:

      Description

      Up to now the document actions that can be selected are hardcoded. You can set access rights dependent on the document type (and the user role). But you can not set different actions dependent on the window or the previous document state or on whatever circumstances.

      Use cases:

      • I want that a document can be completed only after it is printed. That means to look into IsPrinted (this is a bad example because IsPrinted is not maintained in iDempiere but it is just an example)
      • Our workflow says that a document is drafted. When we want to deliver it is prepared. When it is delivered it should be completed. That means a drafted document is never allowed to be completed. If we do that accidentally we get a mess in our business processes.
      • Other users want to Prepare an Inventory Move. Thats not possibel actually.

      The action selection is hardcoded in DocumentEngine.getValidActions()

      I talked with Carlos and we discussed two approaches:

      • Make it configurable by an event plugin.
      • Use a dynamic validation for that.

      Because the second was my idea I want to repeat what I already wrote about that:

      _The DocAction is a field. And a field has a field definition record. And the field definition record contains a configuration for a dynamic validation. This gives a list of things as a result. You compare this list with what DocumentEngine.getValidActions says and use only the entries that are in both lists. That means the dymamic validator allows to filter the standard list of actions.

      The dynamic validator allows to use sql for some magic. And if I am not wrong it allows even to use context variables to change behaviour based on the window, the user or whatever._

      My solution (dynamic validator) seems straightforward for me. It can be used like any other fields dynamic validators and can be used in core. The plugin approach is a bit more flexible.

      A big difference is that a plugin allows to add additional actions. The validator only filters the given. Or do you see a better approach? Do we need to do both things? Is there really a need to add additional actions? Can we give the validator the possibility to not only filter but set the whole list?

      (this belongs to FREIBIER-024)

        Attachments

          Issue links

            Activity

              People

              • Assignee:
                carlosruiz_globalqss Carlos Ruiz
                Reporter:
                tbayen Thomas Bayen
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: