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

Question

Question

Advanced Search Syntax with Token in Web Client

Web Client Search and Retrieval Workflow
Updated February 18, 2019
asked on February 14, 2019

I know there has been an existing issue with advanced search syntax with tokens in the Web Client. For example, {LF:Created<%(Date)}. Has this issue been resolved?

We want to be able to generate search links from workflow to be triggered in Web Client but tokens such as current date will break it.

0 0

Replies

replied on February 14, 2019 • Show version history

I'm confused because you are describing exactly how we recommend people should perform regular searches that require tokens (such as today's date) --- use workflow.

As you note, the client applications don't support tokens in searches, but this should not impact your ability to run a workflow search that uses date tokens, nor should it impact your ability to generate different links based on the current date.

If you are running a search in a workflow, workflow itself substitutes the token before running the search. I just ran a workflow with the search you specified and it returned the correct entries.

If you wish to generate a link to a search based on the date at the time the workflow is run, similarly workflow should be doing this substitution before the link is sent out.

If you are running into an issue where workflow is not substituting the token when run, could you provide more details on what the user is doing and what the workflow looks like?

0 0
View 1 previous reply
replied on February 15, 2019

Hi Brianna,

You are correct. The workflow is working perfectly fine. We are trying to generate a web access url that is then emailed to a user. If the search uses the %(Date) token as an example, it does not return any results because it errors out on the web when the generated web access url is opened up from the email. So from what you've said it sounds like it does not support tokens. Will it be available on any update?

0 0
replied on February 15, 2019

Perhaps I'm misunderstanding what your goal is.

Are you trying to send the user a link that will work any time in the future, substituting in the current date when they visit the link? If so, that is not supported and I can pass this request on to the appropriate team.

If you are trying to periodically send them a link where workflow automatically inserts the current date at the time the workflow is run, that should be feasible.

You should be able to have workflow replace the token before the email is sent so that the URL they see has the current date, rather than the token.

0 0
replied on February 18, 2019

Kevin, can you post a screenshot of the email activity and the email the user is receiving? It's likely your links are not properly encoded and your mail client breaks them when displaying spaces or other similar characters.

0 0
replied on February 18, 2019

Miruna,

You are correct in that the link was not properly encoded. The following is the full search syntax that was needed:

{[]:{Disposition Date] <= %(Date)} & ({LF:id > 0} - {LF:tags = "HOLD"}) & ({LF:LOOKIN="\Records"})

I noticed that the search is changed when launched from email to the web client and removes the quotations around \Records in the within folder syntax. It also had issues when encoding the quotations with %22 because it flips the backslash to forward slash. So that needed to be encoded as well. The following is the syntax that was used when generating a successful web search url:

{[]:{Disposition Date] <= %(Date)} & ({LF:id > 0} - {LF:tags = "HOLD"}) & ({LF:LOOKIN=%22%5CRecords%22})

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

Sign in to reply to this post.

Details
Related Posts
Loading ...