Thank you Alex. I'll look forward to your updates.

We are experiencing the same issue with Version 8.31.625. So what is the Fix?  If I do not give users browse rights to the Records Management Folders the users cannot search for the documents regardless if the Resolve Shortcuts Checkbox is checked in the client.

The whole premise of Transparent Records Management is to not give users Browse rights to the Records Management Folders.

Please advise

I'm not aware of any issues in 8.3. The only issue is that starting in 9.1, the users will need browse on the document itself in order for the shortcuts to return in search results. Again, the consequence is that the search results will now contain both the document and its shortcut.

Actually the consequence only returns the shortcut and not the document as it is not a records management search. However this behavior does occur in 8.3.1.625.

You may want to open a case with Laserfiche Support.

Will do

Support has confirmed that the bug dates back to my client's version of Laserfiche in 8.3.1. As a workaround we granted access to the documents not RM folders. oddly enough when a user searches for documents they only get the shortcuts and not the original in their hitlist so all is right with the world for now.

Thanks

I have this exact issue. I opened up the RM folder to full access, have the options setting for "Resolve Shortcuts" selected but still no search results.  I am searching logged in as an admin with full permissions across the board. 

Any suggestions of an area to check?

Thank you

Please check the effective rights on the documents themselves and confirm if the user in question has browse and read rights on them.

Sorry for the confusion.

The problem for this one was located in between the keyboard and the chair.

I was searching for a "document" when I should have been searching for a "shortcut".

Hi Alex, is there any word on the progress of fixing this bug? Is the intention to have a patch released in the near future? If so, what is the timeline? This issue is affecting usability in production, and assigning browse rights to 100,000's of records with varying degrees of security considerations is not ideal.

Thank you!

There is no eta for when this will get addressed. As it currently stands, users will need browse and read rights on the entries themselves in order for the shortcuts to get returned in search results. Workflow can be used to handle the assignment of access rights.

Okay thank you Alex.  If you hear of any progress on the resolution, please let us know.

This effectively puts a halt to client upgrades who use Transparent Records Management because any that were built prior to this bug will need their security redesigned.  They will either need independently secured record series folders or we'll have to put all documents through workflow to create the unique document security.  Additionally, this adds considerable time to new deployment as we now have to build in extra security, extra RM folders, and additional Workflow activities to accommodate this hopefully temporary issue.  Is there an updated time frame?

Beau: It is definitely a bug, but I'm not actually sure it would have that much impact on the existing security in a TRM environment. The bug is that searching by field only or entry name only where the user does not have browse on the source document will not return results. You do not need to assign browse to each individual document, in many cases the tunnel setup will already have browse in addition to read within the tunneled security - so long as it's present post-tunneling and inherited into the source documents, that's fine too. You would already have needed to provide the tunnel in the first place, so I'm not sure where additional independently secured Record Series come into play. I may be missing a nuance here and I agree it certainly is a bug, but I wanted to clarify exactly what the fundamental impact is.

An example where this comes into play is if I have a Records Series for "1000-01 Contracts, PO's, Invoices, Checks & Bids".  In this example these all carry the same retention for this customer and thus are stored in the same folder.  The Finance department maintains these so they can see them all.  Purchasing can see the Contracts & Bids but not checks.  All internal employees can see the PO's & Invoices but not the Checks, Contracts & Bids.  So we have 3 different views of the documents maintained in a single records series.

Currently the users have Read permissions only on the documents in RM and can access them either via the Shortcuts in their regular LF folders or with a search because Read permissions allow the documents to be searchable in the old versions.  If we go to upgrade them then we have several options:

1. Leave it setup the way it is
   1. The documents will not be searchable via a field search (our user's most common method of searching)
2. Grant these 3 groups both browse and read permissions to all documents in the current Record Series
   1. They will be able to search for documents by template field
   2. They will also be able to see every document in the record series if they run a search that any of the other documents qualify for
3. Setup separate Record Series for each of the document types
   1. Allows the Browse & Read permissions to be set to allow docs to be searchable
   2. Keeps documents independently located to control access
   3. Requires additional setup for Record Series & security 
   4. Requires additional work when destroying records as they are spread out now
   5. Does not account for granting permissions to specific documents such as only contracts that apply to your department (we could previously do this by creating a shortcut in the department's folder which would then be searchable) 
4. Setup workflow to assign document level permissions
   1. Allows the Browse & Read permissions to be set to allow docs to be searchable
   2. Keeps documents independently located to control access
   3. Requires additional setup for Workflow to manage permissions
   4. Requires all documents to go back through Workflow when security changes are made so that they will be assigned the new permissions

With the old method we could handle security easily via the shortcuts but this now puts us in a tough spot where we have to create extra steps to manage security and thus makes the application less dynamic.  For small setups they may never notice this change however for large clients this will create considerable extra work. If this is something that will be fixed in the near future then it is better to hold off than to expend extra time redesigning environments for a bug.  Is there a time frame on when we can expect this resolved?

Since upgrading to 9.1.1 this issue has surfaced for us. Any updates on this? Justin, read your response above but do not understand your explanation of how to resolve. Unless you have other suggestions I have to either open my Records Management folders to users (give them browse) or tell users to search the Records Managment folders for their documents and not the user folders, which totally bypasses the use of shortcuts and TRM. "Resolve shortcuts" in options has no affect. Thank You

You can use access rights scoping to give the users browse on the documents themselves inherited from the parent folder without given them access to browse or read the folders themselves. Then the prior searches should work fine.

Any update on when this will be fixed (patch or 9.2)?  There have been situations where someone ran a search and it returned documents they should not have had access to because we'd had to grant them the Browse permission to the Documents Only in an RM folder so their field searches would work.  This has caused us to have to rebuild their workflow to assign additional permissions to the documents themselves that are stored in RM (beyond the permission already setup for the folder structure where the shortcuts are stored).  Then after making this change to workflow we had to refile ten of thousands of documents so they would inherit there new document level security based on their document type.  If this is to be permanent then we can add that into our scope for new projects but if this will be resolved soon then that wont be necessary.

Beau - I checked with the developer working on this, he's actively working on this area of code and hopes to have it for 9.2 but it apparently has some technical complications such that he's not 100% certain just yet. We're hoping to be able to though. Hopefully I'll be able to give you good news on it soon.

Awesome, thanks for the heads up!

Any ETA on LF 9.2 and if it's going to include this fix.  I have a large TRM project that I'm holding up until this is resolved.

Any word if this is resolved in 9.2?

The Laserfiche Server team is almost done implementing a new Search Processor, we're doing internal testing on it right now on our internal production systems and hope to be able to enable it in the next maintenance update. Among other things, this new processor will address this issue. We had hoped to include it in the 9.2 release but we felt it was best to be a bit conservative about deploying it given the potential internal scope.

That's great news Justin.  Thanks for staying on top of this issue and I can't wait to see what y'all come up with, along with any new/faster functionality with a new Search Processor.

Any update on when the new Search Processor will be available to address this TRM issue?

We are in a holding pattern with moving any more records to TRM and have told users to use the "shortcut" entry type (in Webaccess) when performing searches so they don't see the originals in RM, but you can't force it. If they are full users they are going to see the records in search results and told them to only click on the shortcuts. How are you all handling this situation? 

Our situation is double complexity because we use Weblink internally for casual access via groups from AD, so as we started moving records into TRM and creating their shortcuts, did not realize they could no longer search the documents, because WebLink does not have the "resolve shortcuts" unlike webaccess and full client. Anyone else out there using it this way?

Just an afterthought, but is there a possibility to restrict the users results to shortcuts only via the admin utility in either webaccess or full client for certain groups?

This issue is scheduled to be fixed in the new search processor for the next release of Laserfiche. Note that this is not the soon to be released 9.2 SP1, but rather the next actual release in the version 9 line. We'll keep you posted as we get closer to having an ETA.

According to kb 1013609, 9.2.1 includes this fix: "The Document/Folder Name search type now returns shortcuts when you have the Read, but not Browse entry access right on the source entry. (122246)"

Can you confirm that this is specifically referring to the issue reported here? ("Shortcuts to a document with only the "Read" access right do not show up in search results")

Laserfiche 9.2.1 contains the fix where now when you search by document/folder name (for shortcuts), it will return those shortcuts that point to documents where the user only has read rights on.

The other issue mentioned regarding searching by field has not been fixed yet.