cancel
Showing results for 
Search instead for 
Did you mean: 

Configure Custom Query to not respect rights

Sean_Killian
Elite Collaborator
Elite Collaborator

We need users to be able to use a custom query to search for documents which they do not otherwise have access to (e.g. through the Retrieval Dialog). Though I have the query configured with the “Restrict by Rights” checkbox unchecked, I still receive a dialog that the user has insufficient rights.

I created a user: BERTRANNUS who is a member of the “OnlyTestFeatures” group. The “OnlyTestFeatures” group has access to only the “Separator Sheet” document type which is in the “Test Features” document type group. There is a second document type, “Non-Separator Sheet” in the “Test Features” DTG, which I have configured to appear in a “By Document Type” Custom Query, that uses Keyword Edit Fields, where “File Number” is the only keyword. There is only one document per these two document types in the system. I can open a “Separator Sheet” document from the retrieval dialog and the “Non-Separator Sheet” DT does not appear in Retrieval (as it shouldn't).

I logged in with the MANAGER account to retrieve the “Non-Separator Sheet” document and view its keywords in order to get its “File Number” keyword value.

I log out and then log back in as BERTRANNUS and pasted the “File Number” value into the “File Number” textbox and hit search. From the Unity client, I get a dialog reporting only that “No documents found” but from the Thick Client, I get “You have insufficient privileges to view documents” and then a “No documents found” message.

I am looking at the SysAdmin MRG and I see that:

You may also select the Restrict by Rights option to restrict users of the Custom Query to only those that are assigned to the Document Type.

However, I have this box unchecked, which I would think means that users of the Custom Query should be able to to access the documents without being assigned to the Document Type.

I tried changing the Custom Query type to “By Keyword” which results in bringing back both “Separator Sheets” and “Non-Separator Sheets,” but I notice that though the “Non-Separator Sheet” does show up in the Query results, it is prefixed with “Restricted” and when I try to open it, I get a “You have insufficient privileges to view documents” message.

What other security setting must be changed which will permit the Custom Query to return documents that a user does not have access to?

5 REPLIES 5

[quote user="Marcus Christian, PEMCO Insurance"]

Actually, if I read your requirement, I don't think Custom Query would do what you want (but you might test it in case I'm wrong).

What you really need, is a combination of Required Keywords and Override Query Restrictions for a particular group.  To do that is easy, the challenge is the document type(s) configuration.

Say you have a loan packet.  All documents have Loan Number.  However, Department A can search "blind", Department B cannot.  You'd set whatever keywords as Required for Retrieval (under the Document Type configuration), Set the Document Type settings to Warn and Cancel and require whatever, and set Department A to have the Override Query Restrictions option.  Department B would be required to put something in to get a document.  Department A would be prompted, but they could bypass.

What derails this is the wildcard option, which you can't override by usergroup.  If it's an alpha keyword with no mask it's going to allow wildcards.  You can't stop that for one population, at least not to my knowledge.  The best way of dealing with that is with some fancy HTML and JavaScript/JQuery on the Custom Query interface that blocks wildcard searches; but then you'd have to build two such queries, an "unlocked" one for Department A and a "restricted" one for B.  But that's assuming Custom Query will respect the keyword restrictions, which I don't believe it does.  I think that's only Document Retrieval that would respect the restrictions above.

As a first step I would see if an HTML Custom Query and some fancy scripting would fit the need in a roundabout way, though it requires two queries.

What you seek is doable, but it would take some fancy work.

I was hoping I could get it to work with minimal configuration, however I can see now how a bit of scripting can get the job done.  Thank you for the help!