-
Notifications
You must be signed in to change notification settings - Fork 466
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow users to map workflow actions by content type or workflow scheme #16820
Comments
So I'm not sure if this will help, but a few thoughts that may make the issues clearer:
Final note: The issue of action permissions may also affect things. The simplest way to handle it if the user doesn't have permission for the default action is to throw a permission error. But a more sophisticated scheme may involve trying the default action, and if the user doesn't have permission for that one, then falling back to another one (such as the default action for the "New" workflow step). I think this is an important consideration, but for the initial implementation the simple approach of just giving a permission error is the best approach, and we can add more sophistication to it later. |
…ctions mappin and auto assign workflow step listener too
…dpoints for system action mapping to workflow actions
…tipart, missing more testing and unit test and the cases besides NEW+EDIT
Doc Note: Changes will need to be documented in several different locations:
I think we'll need some testing in these areas to see whether it really comes into play there or not. |
…they are being referred by some content type
…references to it, are being removed and addition the first step can not be deleted nor reordered
…ache for system action mapping in addition to the support to remove mappings from the update content type
Some issues found after performing internal QA You can associate an actionId that doesn't belong into the workflow schema through the end-point In a similar fashion, you can add an actionId that does not belong into the ContentType specified via variable-name If I remove an action from a workflow or remove a workflow from a CT a clean-up process must be performed on table When sending an invalid actionId through the endpoint If I use Please review the logic that detrmins if the action performed must be considered NEW vs EDIT Site-Browsers fires the default action when I perform a cut-n-paste but the action isn't fired if I do a copy-paste. The same behavior can be seen on webDav |
I was not able to reproduce it, I have included something like
the actionId is part of the System Workflow, but the scheme is not. |
"In a similar fashion, you can add an actionId that does not belong into the ContentType specified via variable-name" |
"If I remove an action from a workflow " |
"remove a workflow from a CT a clean-up process must be performed on table workflow_action_mappings to eliminate invalid references." |
"When sending an invalid actionId through the endpoint {{serverURL}}/api/v1/workflow/system/actions The error message must say: FIXED |
"Please review the logic that detrmins if the action performed must be considered NEW vs EDIT great catch, the fix was included on the PP PR |
And what happens if you change the id in bundle? |
Things I had initially found were fixed. |
Fixed, tested on master // Postgres // FF |
When building forms, I want to be able to specify a default action that will be run when a new form is submitted by a site visitor. I would like to be able to do this on a content type by content type level.
Possibly, some time in the future, I would like to be able to specify default actions for content in any workflow that are fired (by default) when content is checked in without a workflow specified. Basically, mapping a workflow action to a dotCMS system action. There are many places in the system where content is checked in without a workflow action specified, e.g. happens in scheduled jobs, webdav, import/export and possibly with PP. While we will implement this now, we need to design the data model to support this.
Technical Approach
My idea is that we create a new table called
structure_workflow_action_mapping
that maps SYSTEM actions to WORKFLOW actions. The mappings can be done at the specific content type level OR a the workflow schema level. The table would look something like:id key action, scheme_or_structure , workflow_action_id, unique index on action, structure_id, workflow_scheme
We also need to create an ENUM called WORKFLOW_ACTION_MAPPING or something that consists of
Initially, we will be exposing the control of this data in only a single place - on the content type builder, where a user can select what action they would like fired when a content of a specific type is checked in via webdav. The entry in the db would look like:
Action Resolution
When a contentlet is checked in without a workflow, dotCMS will check to see if there is a workflow action that has been mapped to
NEW
for the given content type. If so AND if the user has permission to use the it, we will fire that action. If there is one specified and the user does not have permission to it, we should throw an exception.If there is no
NEW
action mapped on the content type, we should "fall back" to check to see if there are anyNEW
actions that have been mapped for the workflow schemes used by the content type.The entries in the db would look like:
If there are
NEW
actions mapped, dotCMS will select the first one returned and fire it when the content is first submitted (if the specified workflow action does not include a save method, it should be fired after the content checkin has completed).Other thoughts:
If a matching action is found but the user does not have permission for it, then we throw a permission error.
If no actions have been set on the content type or on the structure, then we just check in per normal.
We will need an endpoint that can deliver a list of available workflow actions that can be selected so a manager of a content type can select their "default" action. Additionally, we will need to modify the current content type response to send information about the selected default action if it is available.
The text was updated successfully, but these errors were encountered: