Question

Field caching allows users to type invalid values into list fields

Laserfiche

Updated July 29, 2016

asked on July 20, 2016

Hi,

We have several clients with very large lists of data so we use field caching (via the CacheFieldValues and MaxDropDownLength attributes) to mitigate against any performance issues. In doing so however (specifically when also using the MaxDropDownLength attribute) we introduce a data integrity issue whereby users can type anything they like into those fields - there is no validation to ensure what they have entered appears in the list.

It has been suggested that this is expected behaviour when using the MaxDropDownValues attribute but dropping this attribute seems to introduce a stability issue. It would seem logical if there were some integrity checks in such cases to ensure the entered values match a value in the list.

Does this seem like a valid request that may be introduced?

0 0

Answer

SELECTED ANSWER

replied on July 20, 2016

You can force the values to conform to the available values, it is a setting in the Dynamic Fields tab in the admin console:

More information can be found in the online help.

2 0

Replies

replied on July 20, 2016

Hi Nigel,

The option adds server-side validation to the list values. In most cases it's not relevant since the Client applications will perform the validation for you, but it looks like it is in your case.

2 0

replied on July 20, 2016

OK thanks Robert, initial testing seems to be positive. I understood that only applied to SDK applications ("it is not relevant if you are accessing the values through version 8.2 or later of the Client or Web Access" )

Hopefully that will resolve the issue for us!

0 0

replied on July 25, 2016

The field value validation is working well but one thing that did come up is the warning message. Sometimes this mentions the field name and other times it seems to refer to the field index (i.e. "Date validation failed on Field [5]") but not sure why it would appear differently?

Do you know what controls this behaviour and whether it can be changed to always display the field name?

0 0

View 2 previous replies

replied on July 25, 2016

Is the field index always "[1]"? I think it sometimes fails to replace the [1] with the field name.

0 0

replied on July 27, 2016

From my testing it always seems to show [1] regardless of which field is invalid. I can't see a pattern as to why it sometimes shows a name and sometimes an index number.

The client pointed out a couple of other complications when validation is enabled.

It does cause a 6/7 delay when filing the document whilst it performs the validation check but I think they can live with that.

Secondly, when editing field values (whether it be when making an amendment when saving a document originally, or editing an existing document) the validation checks only whether the entered/modified values exist in the entire list and not that they are valid according to the filtered selection. For example, if my list contains a 3 tier dynamic field setup, say Country, State and City then when creating a document I could choose USA, California and Los Angeles and save it. If I then open the document again and edit it, I can choose USA, California and New York so although New York exists in the list it is not valid as a city in California.

0 0

replied on July 27, 2016

I can reproduce the [1] error (I filed bug# 147283).

I can't reproduce the second error, I have a similar state/city/zip setup and I am always blocked from setting the city to a value that doesn't correspond to the state field.

0 0

replied on July 29, 2016

The second error may need a bit more work to recreate, I've spent some time now looking at each scenario and come up with the following conclusions (bear in mind that field caching is enabled):

- When saving a document for the first time, either using the Office integration or importing via drag and drop or the file menu, the validation rules are enforced. The Office integration simply doesn't not allow an invalid combination to be selected and the LF Client displays an error message after importing.

- If we open a document from the Laserfiche Client and change the metadata then the values do not seem to be validated so we can choose invalid combinations of data - i.e. Country = UK, State = California.

So now my test results reflect what the end user is reporting. Are you able to recreate this?

Thanks,

Nigel

0 0

replied on July 29, 2016

I still can't reproduce this, but I filed another bug report (#147371) about having the desktop client validate the values when using the MaxDropDownLength option.

0 0

You are not allowed to follow up in this post.

Question

Question

Field caching allows users to type invalid values into list fields

Answer

Replies

Sign in to reply to this post.