You are viewing limited content. For full access, please sign in.

Question

Question

Change event rule getting in its own way prevents changes from taking place

asked on May 18, 2019 Show version history

I've worked with my VAR on both the Support and Consulting sides trying to resolve this issue, to no avail.

 

All of our documents with a certain Workflow template cannot have pages deleted.  The "Entry Changed" starting rule on the workflow in question triggers BEFORE the page is deleted for some inconceivable reason.  This causes users to get this message every time they try to delete a page:

Clicking "Yes" has no impact on the deletion action, so the page remains un-deleted.  Permissions are set properly on the folder, and other documents in the same folder structure and volume, but that use a different template, do not have this issue, nor do any other documents/templates that I am aware of (I've tested several).  I've altered the starting rule such that it's not SUPPOSED to be running on any change event that has to do with Page activity (we only really need it to run when metadata or tags are changed).  Here are my starting rules as it stands right now:

 

I've tried changing the rules to run only when Entry Changes Include field actions (see picture below), but that resulted in the rule not triggering at all when metadata changes, so that's probably its own separate bug/issue.

If I turn the starting rule off, page deletion can be done without incident, but we do need that change rule for metadata changes.

 

This issue came to my attention some weeks after our LF 10.4 upgrade, so that may or may not be related.  I have also tried the following (none of them worked):

  • Renaming the template
  • Deleting the starting rule and creating a new one
  • Creating an entirely new workflow with its own set of starting rules
  • Adding the functionality I need for this workflow to another workflow that doesn't implode when page deletion occurs, with a decision tree based on the template name

 

Our current workaround is to select the pages that need to be deleted, creating a new entry out of those pages, then deleting the entry.  The fact remains, though, that the Entry Changed activity should not be triggering before the change actually occurs.

 

If nothing else, does anybody know if there's a way to find out exactly what entry change event it was that triggered the rule?  That might at least give us a direction.  I've spent so many hours on this...

 

Thanks in advance for any feedback or input!

0 0

Answer

SELECTED ANSWER
replied on June 11, 2019

This behavior was identified as a bug in the Laserfiche Server and has been addressed for 10.4.1. Reference ID #168516.

0 0

Replies

replied on May 20, 2019

FYI - There is a bug with Workflow 10.4, in that if you open a document and close it, workflow classes this as an entry change. Wonder if this is what's causing you issues..... This should be fixed in the coming 10.4.1 update.

0 0
replied on May 20, 2019

To be exact, the fix is in the desktop client, the Office plug-in and the Laserfiche Server, not in Workflow.

@████████, I'm not seeing a support case for your organization. If you're using something other than the desktop client or the Office plug-in to open documents, could you make sure they open a case with Laserfiche Support?

1 0
replied on May 20, 2019

@████████ thanks for the info.  We're not closing the document before attempting the change, obviously, but it does seem like it could be related.  @████████ we are using the desktop client; should I talk to my VAR about opening a support case?

0 0
replied on May 20, 2019

Are these Office documents where you go into the LF Client and double-click them to open? Do you have the Office plug-in installed on the machine?

If that's the case, it is the same bug as the one discussed above. 

0 0
replied on May 20, 2019

No, these are native Laserfiche documents, trying to delete pages from the thumbnails on the left.

0 0
replied on May 21, 2019

Is the user doing anything else before attempting to delete the document?

0 0
replied on May 22, 2019

No, after it was first reported to me I tried many times and many ways to accomplish the task.  Many of those attempts were just opening the page, right-clicking on a thumbnail, and clicking "Delete page" then getting the error message.  Again, I could change metadata or create new documents from the page, but any attempt to delete the page resulted in the error above.

0 0
replied on May 23, 2019

Please have your reseller open a support case so we can take a closer look.

0 0
replied on May 24, 2019

Hi Sean,

Just wanted to suggest re: your field rules for Entry Changes, you might want to change the group condition from "If all..." to "If any...", since I imagine you want it to run, for example, when a template is assigned, even if a tag is not.

Best,

Rob

0 0
replied on June 7, 2019 Show version history

We have settled on a workaround for this issue.  I've added an empty "repeat" function to the workflow that just iterates pointlessly 500 times to give the page deletion enough time to complete before attempting any locking actions.

While this does work, it's a pretty ugly workaround that shouldn't be necessary for two reasons:

  1. Perhaps most importantly, my starting rules are set to explicitly ignore page changes as a valid starting reason
  2. It seems to me that, even ignoring my starting rule settings, the change rule should not kick off before the change has actually occurred.  Maybe this isn't reasonable due to unknown speeds of SQL and Laserfiche servers, but it still seems off to me.

 

I'm hoping that Laserfiche can address these issues in a future release.

Repeat loop.png
Repeat loop.png (130.9 KB)
0 0
SELECTED ANSWER
replied on June 11, 2019

This behavior was identified as a bug in the Laserfiche Server and has been addressed for 10.4.1. Reference ID #168516.

0 0
replied on June 11, 2019

Great, thanks Miruna!

0 0
replied on June 18, 2019

We did do the update to 10.4.1 and this resolved the issue for us.  Thanks!

1 0
You are not allowed to follow up in this post.

Sign in to reply to this post.