search

SparkDevNetwork / Rock

An open source CMS, Relationship Management System (RMS) and Church Management System (ChMS) all rolled into one.
http://www.rockrms.com
563 stars 345 forks source link

Connection Request Manual trigger Workflows do not behave as expected #5896

Open stanalyst opened 4 weeks ago

stanalyst commented 4 weeks ago

Description

Background: We have a workflow which we want to be able to manually run from both the Person Profile action menu and from Connection Requests. We have the workflow check the incoming Entity Type to know how to get the Person - and the Connection Request when appropriate - then either present a user entry form for confirmation and customization of an email message to send - or a message indicating their request can't continue and why. Additionally we were hoping to not auto persist the workflow and wait to persist until after the Form is submitted. Everything works as expected when run from the Action Menu - but we've discovered that the behavior when launched from Connection Request is VERY different (and not right?).

These are 2 specific behaviors that we believe are NOT right...

  1. Regardless of whether the workflow is persisted or not - it the workflow stops processing at a "Workflow Entry Show HTML" instead of a "Form" action - when the workflow is triggered from a Connection Request - the modal will appear saying the workflow was started - but the 2nd tab is never opened to show the UI for the workflow - so the user never sees what happened or the content of that message. BUT - it does show the UI when run from the Action Menu.

  2. When the workflow is setup to NOT auto persist - if the workflow stops processing at a user entry form - then when run from Connection Request the modal will say the workflow was started and is ready for input ... but when the 2nd tab opens - the user gets an error saying the Entity was not specified

Actual Behavior

As described above ... the workflow's behavior is inconsistent when launched from Person Profile Action Menu vs a Connection Request.

Expected Behavior

The workflow's behavior should be the same (or at least consistent) when launched from Person Profile Action Menu vs a Connection Request.

Steps to Reproduce

Here are 2 workflows - setup the same - except 1 auto persists and 1 doesn't ConRqst WF (Auto Persisted)_202406060901.json ConRqst WF (Not Auto Persisted)_202406060902.json (NOTE: There are 2 Lava Run actions in each with hard coded EntityTypeIds for Person (15) & Connection Request (240) ... with the values for the demo site.) (2nd NOTE: For purposes of this test each workflow is setup to stop at a Show HTML action instead of the Form if the Person has a first name of Wendy ... for the demo site - Wendy Gilbert is a great test candidate)

1 - import the workflows (update the EntityTypeIds in the lava run action if needed) 2 - add these workflows to the Action Menu for Person Profile 3 - add these as manual triggered workflows for an Connection Type

To confirm behavior #1

  1. Find a Person Profile whose first name is Wendy
  2. Run either workflow from the Person Profile Action Menu for Wendy
  3. Run the same workflow from a Connection Request for Wendy
  4. Note the difference in behavior

To confirm behavior #2

  1. Find a Person Profile whose first name is NOT Wendy (Brian Gilbert on the demo site is a good one)
  2. First run the Auto Persisted version of the workflow from the Connection Request
  3. You should see the user form in the 2nd tab that opens
  4. How run the NOT Auto Persisted version of the workflow from the Connection Request
  5. You should see an error message about the Entity not specified in the 2nd tab
  6. Now run the same 2 workflows from the Action Menu - and note the behavior

(LAST NOTE: all of this is currently setup on the demo site if you want to quickly confirm the behaviors today)

Issue Confirmation

Rock Version

16.2

Client Culture Setting

en-US

stanalyst commented 4 weeks ago

Also - a couple of us had a fairly big back-and-forth discussion on this topic in the workflow channel on RocketChat ... might be some more details there that are helpful. Thanks!

JDShuman commented 4 weeks ago

I was able to reproduce this on the demo site. I was looking for an existing workflow I could test on our setup, which is currently running v16.4, but it seems we are currently auto persisting workflows triggered from connection requests. We generally do not auto persist workflows that direct the user to a form, so I'm guessing we ran into this issue and set to auto persist as a workaround.