Skip to content
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

Closed
wezell opened this issue Jul 9, 2019 · 16 comments
Closed

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

wezell opened this issue Jul 9, 2019 · 16 comments

Comments

@wezell
Copy link
Contributor

wezell commented Jul 9, 2019

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.

Screen Shot 2019-07-09 at 12 47 19 PM

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.

@wezell wezell changed the title Allow users to specify a default workflow action for a structure Allow users to map workflow actions by content type or workflow scheme Jul 9, 2019
@wezell wezell added this to the Cody Current milestone Jul 9, 2019
@john-thomas-dotcms
Copy link
Contributor

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.

jdotcms added a commit that referenced this issue Jul 10, 2019
…ctions mappin and auto assign workflow step listener too
jdotcms added a commit that referenced this issue Jul 11, 2019
…dpoints for system action mapping to workflow actions
jdotcms added a commit that referenced this issue Jul 12, 2019
jdotcms added a commit that referenced this issue Jul 16, 2019
jdotcms added a commit that referenced this issue Jul 18, 2019
…tipart, missing more testing and unit test and the cases besides NEW+EDIT
jdotcms added a commit that referenced this issue Jul 23, 2019
@john-thomas-dotcms
Copy link
Contributor

john-thomas-dotcms commented Jul 23, 2019

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.

jdotcms added a commit that referenced this issue Jul 23, 2019
…they are being referred by some content type
jdotcms added a commit that referenced this issue Jul 24, 2019
…references to it, are being removed and addition the first step can not be deleted nor reordered
jdotcms added a commit that referenced this issue Jul 24, 2019
jdotcms added a commit that referenced this issue Jul 25, 2019
jdotcms added a commit that referenced this issue Jul 25, 2019
jdotcms added a commit that referenced this issue Jul 25, 2019
jdotcms added a commit that referenced this issue Jul 26, 2019
jdotcms added a commit that referenced this issue Jul 29, 2019
…ache for system action mapping in addition to the support to remove mappings from the update content type
@fabrizzio-dotCMS
Copy link
Contributor

fabrizzio-dotCMS commented Sep 12, 2019

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
Copy link
Contributor

jdotcms commented Sep 16, 2019

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
Copy link
Contributor

jdotcms commented Sep 17, 2019

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

@jdotcms
Copy link
Contributor

jdotcms commented Sep 17, 2019

"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
Copy link
Contributor

jdotcms commented Sep 17, 2019

"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
Copy link
Contributor

jdotcms commented Sep 17, 2019

"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
Copy link
Contributor

jdotcms commented Sep 17, 2019

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.

Screen Shot 2019-09-17 at 11 40 23 AM

Done

@jdotcms
Copy link
Contributor

jdotcms commented Sep 17, 2019

"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
Copy link
Contributor Author

wezell commented Sep 17, 2019

And what happens if you change the id in bundle?

jdotcms added a commit that referenced this issue Sep 17, 2019
jgambarios pushed a commit that referenced this issue Sep 18, 2019
@jgambarios
Copy link
Contributor

@fabrizzio-dotCMS
Copy link
Contributor

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

@bryanboza
Copy link
Member

Fixed, tested on master // Postgres // FF

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment