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

Question

Question

[Bug] [Forms] [On Premise] Collections, Lookups, Read Only Fields and Saving Data

asked on May 3, 2021

Hi team,

I came across a weird issue when using a Collection that contained read only fields that were populated by a Lookup not saving data upon submission in Laserfiche Forms 10.

The use case is to provide users with the ability to easily update the details of their "Open Tickets" in a controlled way via form submission using a Collection.

More specifically, we want to allow users to change for example, the Primary Contact details of a ticket by being presented with a drop-down list that populates other read-only fields (e.g. First Name, Last Name, Title, Email) with the data from a lookup.

To start, we use a Collection populated by a data-source. The purpose is to update Tickets, not add or remove them. As a side note: We use CSS to remove the ability to delete. 

Using the above Collection configuration, we add several fields regarding the current "Account Manager" information.

A read-only input field shows the current "Account Manager" which populates as expected, along with several other hidden read-only fields (first name, last name, title etc) for each ticket returned by the lookup rule. e.g. "John Doe"

When "Change Account Manager" is selected, the user is presented with a drop down field "Select New Account Manager" that is populated by, in our case, an Active Directory lookup rule.

Upon selecting the user from the drop down, their title, first name, last name etc, are populated by lookup rules into the relevant fields e.g. "Jane Smith". These fields are read-only to ensure data integrity. The information displays correctly on the front end.

This is where it gets weird.

If you submit the form, the collection ignores any data populated in the read-only fields that were populated by the lookup. Instead, it retains the originally looked up collection values. However, if these fields (first name, last name, email etc) are made editable, they save their values correctly.  Mind boggling.

Current Workaround / Solution

So, our current workaround is to make the fields for first name, last name etc editable/not read-only and hide them using a custom css class (or field rules). This is problematic for fields where we want to display information to the end user but can't enforce constraints (e.g. free text fields, email addresses etc).

I haven't had a chance to test this with LF11 yet but I've been able to reproduce this issue consistently on LF10.

Are others able to reproduce this issue? Any thoughts on this behaviour?

I'd like to mention that when you use "Range of Sets", "Fixed Number of Sets" the issue does not occur and read-only fields populated by lookups commit data as expected.

CC: @████████ @████████

0 0

Answer

SELECTED ANSWER
replied on May 11, 2021

Confirmed this was the aforementioned bug 292893 that is fixed in LF 11. The workaround for LF 10 is to make the fields read-only using JS. 

1 0
replied on May 11, 2021

Thanks Jared!

0 0

Replies

replied on May 3, 2021 Show version history

We'll investigate. Couple of questions: 

How are you making the fields read-only? Is it at the field level, section level or form level for the user task? 

What version of Forms are you on? 10.?.?.?

Have you tried using CSS to make the fields read-only? This is probably your quickest workaround to the bug. 

This also sounds familiar, so I'm going to see if this was a bug we fixed after Forms 10. 

1 0
replied on May 3, 2021

Good questions, apologies for not including that information in the first instance.

Laserfiche Forms Professional Version 10.4.5.282

Regarding how we're managing read-only attributes, currently we are doing it via the field level properties in the designer. Nothing fancy.

Quick reminder, in LF10 sections are not supported in collections - which was a painful discovery when it came to field rules lol.

Also, I'm sure it is of no consequence but you asked if read-only was set at the form level for the user task - another good point I missed. I can confirm in this case, we're working with a starting form that lets users create (Collection 1 - TKNEW) or update tickets (Collection 2 - TKUPDATE) so I haven't tested it as a user task.

I haven't tried using CSS, but I could look into that. The users in this case are internal employees and not hackers, so that could be a suitable work around.

It may have come across your radar recently as I did raise a support case last week regarding this problem to confirm I wasn't mad, and they were not able help me resolve the issue. I've only had a chance to post my findings here today to confirm I'm not missing something and to let others know about the behaviour. The new layout designer in LF11 is superior in a few ways, and I'm sure along with the nested section support this issue probably was fixed/resolved. But if not, it would be worth checking anyway.

Cheers regardless for noting it and hopefully it isn't too difficult for the team to fix!

If you need anything from me, feel free to reach out.

0 0
replied on May 10, 2021

We investigated this a bit and couldn't reproduce the exact issue described. We could only get something similar reproduced if we saved a draft before submitting the form. Was saving a draft at all part of the process? We also checked both your steps and the steps + saving draft on Forms 11 and couldn't reproduce. I see a bug (292893) about values in a read-only table not being saved using the as new rows setting that was fixed in LF 11. It's possible this is what you are hitting. 

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

Sign in to reply to this post.