Allow users to map workflow actions by content type or workflow scheme

[wezell]

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

NEW
EDIT
PUBLISH
UNPUBLISH
ARCHIVE
UNARCHIVE
DELETE
DESTROY

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:

uuid, NEW, contentType1, action1

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 any NEW actions that have been mapped for the workflow schemes used by the content type.
The entries in the db would look like:

uuid, NEW, scheme1, action1
uuid, NEW, scheme2, otherAction

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.

[john-thomas-dotcms]

So I'm not sure if this will help, but a few thoughts that may make the issues clearer:

1. There's an important distinction between new content and existing content.
   • With new content, there are 3 things that need to be done:
     • Select a workflow (for the case where a content type has multiple workflows assigned).
     • Select a workflow step.
       • Note that we can bypass this by automatically picking the first step of the workflow - but that's still a selection of a step.
     • Select a workflow action to take.
   • With existing content, it's simpler.
     • Existing content is already in a workflow, and already in a workflow step, so those don't need to be selected.
     • So the only thing that needs to be selected for existing content is the action to take.
2. For the initial case, we only need to worry about new content (for the new Form builder).
   • But the data model needs to be built to be able to support default actions for existing content too (for future enhancements).
3. The selection of the default action to take for new content has to be specified (in some manner) within the content type, not the workflow.
   • Because for new content, which workflow to use must be selected, and the list of assigned workflows is part of the content type, not the workflow.
4. But the selection of which action to take for existing content can potentially be done in the Workflow.
   • Because the only thing that needs to be selected for existing content is the action (which is part of the workflow).

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.

[john-thomas-dotcms]

Doc Note: Changes will need to be documented in several different locations:

1. Changelog
2. Workflows
3. Content API
4. WebDav
5. Import
6. Possibly push publishing?

I think we'll need some testing in these areas to see whether it really comes into play there or not.

[fabrizzio-dotCMS]

Some issues found after performing internal QA

You can associate an actionId that doesn't belong into the workflow schema through the end-point {{serverURL}}/api/v1/workflow/system/actions

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 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:
"The workflow action with id: 17309ed0dcb does not exists"
currently, it says "The workflow id: 17309ed0dcb does not exists"

If I use /api/v1/workflow/system/actions to create a new entry and I send an invalid ContnetType var name the response should be 400 BadRequest.

Please review the logic that detrmins if the action performed must be considered NEW vs EDIT
workflowAPI.findActionMappedBySystemActionContentlet (contentletIn, UtilMethods.isSet(contentletIn.getIdentifier())?WorkflowAPI.SystemAction.NEW:WorkflowAPI.SystemAction.EDIT, user);
isn't this logic backward??
I mean.. if it doesn't have an identifier it should be new and not otherwise.

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

[jdotcms]

I was not able to reproduce it, I have included something like

{
	"actionId":"ceca71a0de",
	"systemAction":"NEW",
		"schemeId":"e768b36551"
}

the actionId is part of the System Workflow, but the scheme is not.
I have got 400 "buffer": "java.lang.IllegalArgumentException: The Workflow Action has to belong the workflow Scheme\n\tat

[jdotcms]

"In a similar fashion, you can add an actionId that does not belong into the ContentType specified via variable-name"
FIXED

[jdotcms]

"If I remove an action from a workflow "
When remove an action (destroy an action) it is being removed from the content types and scheme referrer.

[jdotcms]

"remove a workflow from a CT a clean-up process must be performed on table workflow_action_mappings to eliminate invalid references."
FIXED, now when a workflow is unselected on the content type and the default action is part of this unselected scheme, the mapping is being removed

[jdotcms]

"When sending an invalid actionId through the endpoint {{serverURL}}/api/v1/workflow/system/actions The error message must say:
"The workflow action with id: 17309ed0dcb does not exists"
currently, it says "The workflow id: 17309ed0dcb does not exists""

FIXED

[jdotcms]

If I use /api/v1/workflow/system/actions to create a new entry and I send an invalid ContnetType var name the response should be 400 BadRequest.

Done

[jdotcms]

"Please review the logic that detrmins if the action performed must be considered NEW vs EDIT
workflowAPI.findActionMappedBySystemActionContentlet (contentletIn, UtilMethods.isSet(contentletIn.getIdentifier())?WorkflowAPI.SystemAction.NEW:WorkflowAPI.SystemAction.EDIT, user);"

great catch, the fix was included on the PP PR

[wezell]

And what happens if you change the id in bundle?

[jgambarios]

PR:
#17267
#17273
https://github.com/dotCMS/enterprise-2.x/pull/678

[fabrizzio-dotCMS]

Things I had initially found were fixed.
Corroborated default actions are no longer fired from site-browser actions.

[bryanboza]

Fixed, tested on master // Postgres // FF