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

Discussion

Discussion

Forms - Copying a form does not copy field rule configurations

posted on July 16, 2020

When copying a form, the field rules are copied, but specific configurations for saving the data are not copied over. This can make the form work differently since field rules can act on data depending on if it is saved or not.

We often copy a form as a way to back it up, but the backup will not be exact using this method.

0 0
replied on July 16, 2020

Hi Chad,

It was identified as a bug for the issue that field rule data option is reset to ignore when copying form. Sorry for the inconvenience it has brought.

The bug has been fixed in latest release Forms 10.4.4. 

 

For your case, is that possible to copy entire process as backup? Or upgrade to Forms 10.4.4 should eliminate the issue.

1 0
replied on July 17, 2020

Hi Ziyan

Thank you! Firstly we just want to ensure that a copy is a complete copy for backup purposes, but also for the client who brought up the issue, they work with a lot of mobile users running very small screens/high dpi.

They have many field rules set to keep the data but hide the field, in order to get it off screen and utilize the screen space as best as possible.

When working on a new version of the form it has been very tricky to copy and create a development iteration because so many field rules would break. With the new version they will now feel comfortable copying their forms for new development again.

They are having sort of the opposite situation as Kris is having, but I think anyone developing for Mobile users is going to run into this problem if the field rule configs don't stick since save the data is needed for temporary hiding of a field to save screen space.

Thanks for the quick fix.

2 0
replied on July 16, 2020

What version of Forms are you using? Are you saying that when you copy a form (not the entire process, just the form within a process), the setting to save the data vs ignore the data is not being copied correctly? We can investigate that as a bug. 

Are you sure the setting wasn't changed after the copy was made? 

1 0
replied on July 16, 2020

I just tested on 10.4.3.198 and yes, copying a form inside a process reset "Save the data when ..." to "Ignore".

1 0
replied on July 16, 2020

I am using 10.4.2.381. Yes this is only copying a form within the process, not the entire process.

I am sure it loses my setting immediately after copying, made a fresh process and form to test.

1 0
replied on July 16, 2020

Thanks for the info, we'll file the bug and get it addressed. 

0 0
replied on July 16, 2020

@████████

This "bug like" behaviour is useful for those of us who create one master form as one "giant" multi-stage template (with immense pages of field rules - think 50+ rules). We copy from the master template form to create the subsequent "forms" that make up a process. 95% of the time we don't want data on Form 2 overwriting data from Form 1.  So this "bug" has been useful in resetting the field rules so that we could choose what data we wanted to saved/be overwritten in Form Copy 2, 3, 4 etc.

I'd like to request we're given the option when "Copying a Form" to retain or forgo Field Rule Save settings, if possible. Thank you.

1 0
replied on July 16, 2020

In most cases, if a field is conditionally hidden, the setting would be set to ignore data when hidden, and if a field is always hidden, the setting would be set to save data when hidden. To me, it sounds like when field rules are copied, you'd want to retain that concept of ignoring data in the conditionally hidden fields and saving data in always hidden fields. 

Kris, what kind of field rules are you dealing with where the rule should sometimes save data and other times ignore data? 

0 0
replied on July 16, 2020

Hi Jared,

It is less about the specific field rules and more about designer workflow. 

I can fully appreciate the need to save the rules exactly as they were written when backing up a form or expecting a true copy. Hence asking for it to be optional.

However, there are a couple of use cases where that isn't the behaviour you want by default.

Firstly, if you work with a lot of hidden variables - based on current user, date/time submitted, lookups, calculated "staging" fields etc. When you copy a form, you are normally doing this to create the "next" stage of a process. Thus, you absolutely do not want your hidden variables being overwritten by default, and your preference would be for hidden fields to be ignored in the second form. I think someone at Laserfiche realised this early on, hence it potentially being the way it is.

Secondly, we've built 100's of processes using Laserfiche Forms and we don't build the forms that make up a process piecemeal. Instead we start by mapping out all fields, sections, pages, rules and lookups in a "master form". That way we can test field rule functionality to see that sections are hidden and shown across all "stages" of a process.

We then take that master form, make a copy, name it for that stage of the process, and then delete all of the irrelevant sections and fields. If you fix this "bug", we will be required to set field rules copied from our master form templates to ignore since every copy is always a derivative and thus should not overwrite the previous step's values when hidden.

Below is an example of where deep into a process, we only had to set one variable to save data, as the rest is in reference to values that were set in a previous step.

As mentioned earlier, I absolutely agree that we should have the ability to backup or copy a form 1:1, but I would certainly appreciate if there was the option to choose which behaviour is used at the time of copying since some of our "master templates" can have over 100 field rules which we'd need to change to "ignore" every time we make a derivative.

Thanks!

1 0
replied on July 17, 2020

Sorry Kris, I missed that this bug was already fixed and released in Forms 10.4.4.

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

Sign in to reply to this post.