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

Question

Question

Search bug? Repository search with links returns seemingly incorrect results

asked on June 6, 2022

Is this a search bug, or am I doing something wrong?  I'm trying to find all documents of a certain type that have any kind of link (relationship) with another document.  If I set up the search so that it looks for "at least one" and select ALL relationships, I get 204 results.  If I select only the "Related Record" relationship type, I get 309 results.

That seemed strange to me, so I started digging.  By doing an individual search on each relationship type, I found that this type of document has one of four different relationships.  If I select only those four options on my search, I get 326 results.  That's the correct number, as far as I can tell from compiling individual searches and subtracting duplicates.

Am I doing something wrong, or is the search algorithm breaking down somewhere along the way?

I've tried this in both the Windows client (v 10.3.1.502) and the web client (v 10.4.2.347).  Same results either way.



1 0

Replies

replied on June 6, 2022

It's certainly odd. The query strings are cut off in your screen shots, would you mind pasting in the whole strings? Maybe there's a piece at the end that explains the difference.

0 0
replied on June 7, 2022

Yeah, I checked that.  I didn't see anything strange, but maybe you'll see something I don't:

{[JCSO Warrants]:[Status]="Inactive"} & ({LF:Relationsrc="2"} | {LF:Relationdst="2"} | {LF:Relationsrc="4"} | {LF:Relationdst="4"} | {LF:Relationsrc="5"} | {LF:Relationdst="5"} | {LF:Relation="3"} | {LF:Relation="6"} | {LF:Relation="8"} | {LF:Relationsrc="7"} | {LF:Relationdst="7"} | {LF:Relationsrc="1"} | {LF:Relationdst="1"})

0 0
replied on February 19, 2024

Were you ever able to get an answer? I am having the same issue with Searching, both in Name (just searching for documents and not folders or shortcuts) and also trying to search a specific user. I believe this may be something out of my control...perhaps a bug? I have asked our vendor and they have been in touch with Laserfiche Support I think? But it's difficult to do QA when you can't trust the results.

Below is the results I am seeing when trying to search a certain tag with the entry name beginning with FC and I only have "Documents" checked.

0 0
replied on February 20, 2024

Sorry Veronica, I never did get an answer.  It is most likely a bug, but I'm not sure if it was ever officially recorded as such

1 0
replied on February 20, 2024

Thank you Sean. We are seeing this behavior quite often now. I appreciate your response.

0 0
replied on February 20, 2024

Follow-up question regarding your issue in particular: Is the issue that it is returning results that do not have the tag?  Can you provide the search syntax that is generated when you run the search?

0 0
replied on February 20, 2024

Here is the syntax:

{LF:Name="FC*", Type="D"} & ({LF:Tags="PD Only"}) & {LF:LOOKIN="CriminalJustice\Police Services"}

 

And it only returns shortcuts with a tag. The expected result for me would be only documents with a tag and if there were none, then no results. After doing some more research, it looks like the "Document" button is used to identify tif images (document type), which seemed very confusing to me because that was every shortcut in our repo. The Document button also has a folder button and the shortcut button, so I was thinking by only selecting the Document button, it would filter out shortcuts, but that was not the case because the shortcuts are tif images.

0 0
replied on February 20, 2024 Show version history

Ah, yeah, searches get weird when shortcuts are involved.  Try excluding shortcuts by directly altering your syntax with an exclusion clause, like this:
({LF:Name="FC*", Type="D"} & {LF:Tags="PD Only"} & {LF:LOOKIN="CriminalJustice\Police Services"}) - {LF:Name="*", Type="S"}

I'm not 100% certain that will work the way you want it to, but in theory it should...

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

Sign in to reply to this post.