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

Question

Question

Laserfiche 9.1 and 9.1.1 problems/bugs. Please help!

asked on February 19, 2014

We have had several problems since upgrading to Laserfiche 9.1. We were on 9.0.3 but after hearing about some of the “great features” of 9.1 at empower we decided to upgrade. What a huge mistake that was. I posted about 2 of these issues earlier but I did not get anything useful and have since opened a service ticket with our VAR. We have basically been holding out hope that 9.1.1 would fix the problems unfortunately that was not the case. So I am turning here for help one again in hopes that someone takes this seriously. Below are the list of bugs we have found so far.

  1. After upgrading from 9.03 to 9.1 and 9.1.1 the laserfiche client became unusable when logged in as a windows user with multiple folder level restrictions. Just navigating around the client would cause it to lock up or crash. This was not the case when logged on as an admin level user that has permissions to see all folders.
    1. Our VAR suggested that we delete all user attributes and have them try to log back in. This did resolve the issue but, it did not seem right. As simple upgrade should not require something lack that.
  2. After upgrading from 9.03 to 9.1 or 9.1.1 we were no longer able to print to laserfiche. I discovered that if we had any users that had not saved a default snapshot profile they were able to print to laserfiche without issue.
    1. After the VAR was finally able to tell us where the default profile is saved (it’s in the registry for those that are curious) I deleted the registry key and printing to laserfiche worked just fine. Once again a solution yes, but is still not right.
  3. After upgrading workflow all logic decisions were reversed. For example if a decision based on a filename in the workflow editor said do this if the file name contained “something” when the workflow ran it did not perform as expected. Upon investigating the workflow activities we realized that the workflow was processing with the decision to run if the filename did not contain “something”.
    1. Once we got over the initial confusion of the logic being listed one way in the designer yet processing in the opposite way, we accidentally discovered that all you to do is go through and republish each workflow and it would fix the problem. We still have now idea why but it worked.
  4. The other and much more serious problem is very, very bad search performance for users with restrictive folder level permissions. The biggest problem with this is that it renders the integration between laserfiche and Junxure useless. This is a huge problem for us because it kills the functionality of or document management system and our CRM.
    1. A simple folder search for a folder with a specific metadata field (exact syntax {LF:Name="*", Type="F"} & {[]:[id]="945"} takes anywhere between 10 minutes and 44 seconds to 18 minutes and 46 seconds to run when logged in as a standard user with restrictive folder level permissions. If I log in to laserfiche as the admin user or a user that is allowed to see more folders the search will run in 1 second. That’s an 18 minute and 45 second difference! WTF!
    2. For testing purposes our VAR suggested that we enable bypass browse permissions for one of the standard users with all of the folder level restrictions. With bypass browse the same 18 minute search takes 46.3 seconds. However, this is not a viable solution for us. Our entire laserfiche security structure is designed around bypass browse being disabled. Not only that but worked in 9.0.3. Why the drastic difference in security behavior? You should not have to redesign your entire structure when performing a simple version upgrade!
4 0

Replies

replied on February 19, 2014

For #3, the initial release of Workflow 9.0.2 had a bug with evaluating conditions with the wrong operator. It was hotfixed with KB 1013233 about 10 days later. I think if you made all your workflows with that initial version, you would run into the behavior you're describing after the upgrade. It was an issue with how the Designer was saving the operators in the WF definition when publishing. Republishing would save the conditions correctly as you noticed.

1 0
replied on February 19, 2014

So, this will happen on all workflows created or edited in that version with every upgrade going forward? Like I mentioned it is not a terribly difficult fix, but it is time consuming and chances are I will forget to republish between upgrades. Is there any way for me to stop it form happening in the future short of recreating the workflows form scratch?

0 0
replied on February 19, 2014

It will happen to any workflows that haven't been republished since the upgrade. They need to be opened once and republished. It will not affect new workflows. It will also not be a recurring issue in future upgrades (since it was caused by a bug, not a functionality change).

0 0
replied on April 4, 2014

We are also having issues since upgrading from 9.0.2 to 9.1 and then to 9.1.1.  We were hoping that 9.1.1 would take care of the issues, but it hasn't.  We have two MAJOR issues.

   1.  In Workflow, users are unable to update document metadata through the Laserfiche tab in Word. However, users can update metadata when not in Word (by right-clicking on the document and choosing metadata, etc.).  This was not an issue in 9.0.  The "Permission denied" error message references the OfficePlugin.  (We are working with Matthew Freeman on this issue.)

   2.  In one Workflow, a shortcut of an original document is sent to 3 different folders.  After one user checks out the document for review and then checks it back in (and it IS checked in), when other users try to check out their shortcuts, they are told "Document could not be checked out" with no further error message or details.  I call this the "phantom check out."  In order to undo the "phantom check out," an Administrator must double click on the document via Client and go to the LF tab in Word and choose "Undo Check Out."  Unfortunately, this sometimes throws the document out of the workflow and/or erases the template data and/or changes the template.

1 0
replied on February 19, 2014

For #2, I believe that the issue was that there was a new registry key added for Snapshot that didn't correctly have a default value. So if you had an existing profile (new profiles post-9.0 were created with it) and not that key, Snapshot got confused. If this is the same issue the key in question was 'ImportToRepo'. In Snapshot 9.1.1 this now defaults to TRUE if not explicitly listed. This doesn't help in your case since you already encountered the issue in 9.1, but it is addressed going forward, and I wanted to provide information at least as to what you probably ran into.

 

I spoke with Support and it sounds like they are working with you VAR on item #4. There were quite a number of Search changes for 9.1 focused around two major enhancements. The first was metadata searches being added to the full-text search index and the second was more intuitive (google-like) searches in the Client applications. Hopefully Support will have success in determining the change that impacted what you are running into.

0 0
replied on February 19, 2014

This is not a response to the original question, but I noticed 3 people marked that they 'had this question to'. If you did so, does this mean you also have ongoing upgrade issues? If so, what are they, or are you currently working with Support on them?

0 0
replied on April 25

I recently just upgraded a user from 9.2 to 10.2 and when trying to print to Snapshot they receive the error:

 

"There was an error creating the document.  Permission denied."

 

The user didn't have any issues printing to snapshot before the update.

Any ideas on a fix?

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

Sign in to reply to this post.