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

Discussion

Discussion

FEATURE REQUEST: Ability to insert the same field multiple times on a Laserfiche Template

Laserfiche Ideas Self-Hosted Version 12 Feature
Updated March 31
posted on February 16

Laserfiche Repository Web Client - 12 (12.0.2510.1022)

Laserfiche Repository Access - 11.1.2509.684

We would love the ability to use the same field, multiple times. NOT a multi value field, but being able to separate it out.

For example: We have three types of addresses - addresses dynamically populated using GIS, addresses that are historical and do not exist in GIS, and intersections only.

Our addresses are broken out into Street Number, Street Direction, Street Name, Street Suffix, Unit Number.

I show/hide based on if the user picks regular address, historic address, or intersection. BUT, I would like this data to be using the same field, so when a member of our community searches for the address, a street name is a street name, no matter the address type.

  

0 0
replied on February 17

Hopefully this helps. From an internal perspective, we are looking to capture 3 different "types" of addresses, but when a (public) user searches for a street name using Weblink, it shouldn't matter if it was an intersection, an address that doesn't exist in GIS, or one that does. I know there has to be some other way to deal with this in addresses, but the big thing is that we dynamically populate the addresses using our GIS as much as possible, but sometimes they don't exists. Please see attached.

Same Fields Feature Request.pdf (200.95 KB)
Download
1 0
replied on February 17

Ok, I understand the problem now. It will take some playing with, but you can actually construct your own search syntax in Weblink. I think you'll want something like this:
 

Create search form with custom fields for address fields. Current/Historical addresses have the same fields. We want to map on search field to either of two fields Current or Historical.



Then you can build your search something like this


Now your intersections, assuming all documents have it can be included as direct field searches below and appended to the query!

It might not be perfect, but should get you closer to what you're looking for.

2 0
replied on February 18

Actually, could you combine all of your fields including address type into one multi-value field group? You could still use field rules to show/hide intersection, but your other two address fields are identical outside of labeling which would be handled by the address type dropdown.

1 0
replied on February 19

Not quite. If we take intersections out, the other two are identical EXCEPT one is pulling data from GIS and populating and the other is a free text fields because it is an address that no longer exists.

0 0
replied on February 17

Why can't you just use the one field there? I'm assuming you are changing the field label so the user can see "hey this is a historical address not an intersection". Could you just use the new "static text" field to have each of you three address type names that denote the description of the field below it? The static text fields could be toggled by field rules where the address fields stay the same.

1 0
View 4 previous replies
replied on March 19

I will have to look into that a little further. Intersections and Current addresses are pulled from a table and historical addresses are a free text field. Can both of these scenarios be done in one field? This is what I built and it seems to be working well. Addresses are complex!

0 0
replied on March 19

If they are pulled from the same table, you could combine them and use rules to show hide based on the address type. If they are in separate tables you unfortunately will be stuck with two fields.

1 0
replied on March 19 • Show version history

Yuppers. One has a table and the other does not. That was the reason for the feature request...I was hoping to insert the same "field" twice, then depending on address type, it would either pull from the table or be a free text field, but when workflow processes it or someone searches that field, it would all come up in one field, instead of two. I know there are ways around it using workflow or views in weblink, but I was hoping for the first option.

So, I would love to keep this on a Feature Request List!!

0 0
replied on March 20 • Show version history

I'd recommend trying out Field Formulas, available in version 12.

The ability to set a field to another field is already present, and it can be made conditional using more complex formulas such as IF.

If the source field (dynamic field) is blank, then the destination field will also be blank. As long as the dynamic field isn't re-evaluated, then the destination field can be manually completed.

If the dynamic field will be repeatedly re-evaluated, then you can use the new option coming in April, "Fill only when blank", that only evaluates field formulas if the destination field is currently blank, preventing field formulas from overwriting manually entered values.

0 0
replied on March 20 • Show version history

That's a good feature but not what I am looking for. One set of addresses uses a dynamic table and would be filled in, the other set would be free text because the address used to exist, but doesn't anymore. They would be separate information that allowed the user to capture one or the other, but never both. After submission, the end user/public user could search "Mason" in the street name and it would appear. They wouldn't have to search street name and historical street name separately to find out where it lives. This feature request would be helpful to keep the ever clustered city addresses in some type of organized manner!

0 0
replied on March 30 • Show version history

You could then add a third field that combines the two possible sources for information. You can also improve user input by doing things like using a field rule that hides the old address unless the dynamic address is blank.

E.g.,

Document 1

Dynamic Address:
411 East Beach St.

Old Address: <blank>
 

Searchable address:  <set automatically to 411 East Beach St.>

Document 2

Dynamic Address: <blank>

Old Address: 555 Lemon St.

Searchable address:  <set automatically to 555 Lemon St.>

 

I recommend exploring the many options in this thread to find the one that best works for you, as your request both overlaps with a lot of existing functionality and is too challenging to implement to be a new feature.

I do appreciate the detail on your use case! It helps us improve existing features as well.

1 0
replied on March 31

I do like this option Brianna and will definitely look into this. I will definitely explore a little more, but I think we have found an option that works for us for now.

Thank you!

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

Sign in to reply to this post.

Details
Attachments
Related Posts
Loading ...