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

Question

Question

Allow Dynamic Field to filter with "contains" instead of "starts with"?

Laserfiche Search and Retrieval Feature
Updated April 1, 2021
asked on March 16, 2021

I have been unable to locate a setting that allows a Dynamic Field to be filtered using the "contains" approach. Is there something I'm missing? If this is not currently available, are there plans to add this functionality?

 

I did find a 2015 question, https://answers.laserfiche.com/questions/79362/Auto-Complete-, but nothing more recent. Like his example, I would like a single field "Rolling-Stock:Autos/Equipment: E211 - JD970" where the user can type either "Rolling" or "E211" and "Rolling-Stock:Autos/Equipment: E211 - JD970" is selected.

0 0

Replies

replied on March 17, 2021

Hi Danielle,

I believe 'contains' is remains unsupported, partially due to performance reasons.

Have you explored Niqi's suggestion in that original post? She recommended splitting out the portions a user would search for and using dynamic fields dependencies.

E.g.,

Type (optional): [ Rolling ]
Part number (optional): [ E211 ]

Full Part Name:[Rolling-Stock:Autos/Equipment: E211 - JD970]

 

Where the user could select a Type and/or part number, then the "Full Part Name" would be narrowed or autoselected.

 

Example table in SQL to accomplish this:

0 0
replied on March 18, 2021

Hi Brianna,

Thanks for your response.

My users are importing lots of documents. Half of them know the part number and the other half need the descriptive name.

By using a single field, it reduces the import time and effort for each document. Also, by having one field, it simplifies our searches.

Since having the 'contains' functionality will significantly improve our processes and our users' experience with Laserfiche, how do I formally request this functionality?

0 0
View 1 previous reply
replied on March 19, 2021 • Show version history

To clarify, the recommendation is adding the additional fields (Type and Part numbeR) only for ease of use by dividing it into the pieces people can recognize, not as something users must fill out. 

The step of filling out that last field would either be with no additional work for the user importing (e.g., if the part number sufficiently identifies the full part name) or with only one more click (select from the narrowed list if they select type). They would not need to use both fields.

Futhermore, someone knew the exact name, they could choose to just select it directly and completely ignore the other two fields.

For search, since the recommendation is to have to full field autofill based on selection from one or both of the other two, the full name would always be filled out, and thus you could still rely on that full name field for searches.

 

Regarding making it an official request: I will take the request back to the team , but a "contains" filter is significantly slower in most cases so I do not think it will be feasible. 

This type of use case is actually is one of the main reasons for using dynamic fields at all rather than regular list fields: to allow users to optionally filter down the long list by entering simpler information they already know.

It's like a filter for postcode: users could enter state and/or city, or just directly start typing the postcode if they know it. If they directly enter the final code, they don't need to enter the state and city since the only purpose is to help them enter the postcode.

0 0
replied on March 22, 2021

My apologies for not being clear in my request.

Instead of using the parts example, here's a simple list of Department Names with their corresponding Department Codes.

I would like to have a single Department field. Since the users know most of the Department Codes, it's much quicker for them to type in the number. Also, as they type the Department Code, the Department Name will appear and validate their choice. This would be a significant time savings for the users.

By having the "contains" approach as an option, we could determine on a case-by-case basis if it performs fast enough for the users. Then, the users would know we're optimizing the lists and streamlining their processes using the most efficient approach for that scenario.

1 0
replied on March 25, 2021 • Show version history

I do appreciate the additional information and I understand why you want 'contains' within a single field, but it is technically challenging with negative performance impact and thus less likely to be implemented, so I am trying to provide a workaround that mimics the functionality.

Here's what I am trying to describe. There's a template that has three fields instead of one:

Then a user can select the 100 code:

Since the code uniquely corresponds to a department, the other values autofill immediately --- no additional user clicks:

But if someone doesn't want to enter the code:

They don't have to.

This is done by setting up dynamic fields for the template in the following way:

Where the short name is dependent on the code, and the full name is dependent on the short name.

Unfortunately, I did misremember an important aspect of how dynamic fields work. In order for users to be either to pick either code or name, you need "null" values for code in your external table and some duplicate entries:

I understand that it's not exactly what you asked for, but does this help? The way I've set it up, the user still only makes one selection from a list, and the full name is always present in the same field.

 

Note: you can swap which part has the null values (short name null, code always completed) as long as you swap the dependency order (full name dependent on code, code dependent on short name). 

0 0
replied on April 1, 2021

Thank you for providing the ideas and the screenshots! Now I have a better understanding of what functionality is available. I appreciate your help!

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

Sign in to reply to this post.

Details
Related Posts
Loading ...