Element-Validator(s) fire for a form even if the user have no edit permission for that element

[burghard]

I defined a validator on an element. If that element is part of a form but without edit permission for the actual user of the form, the user is not able to save the whole form.

It would be nicer, if the validation is only done (and only blocks), when the user is able to edit the element. Otherwise it will block him without a chance to modify other elements of the record.

 

[Sophist]

@burghard - Unfortunately it is not quite that simple.

Firstly read-only permissions could come in several (at least four) forms. (I am not saying that this is how Fabrik works, just explaining different types so that we can understand which type yours is.)

1. The element's Access Level is r/w, it is written to the database on save, but the input field is made read-only but is still submitted to the server. Using javascript the value of this can be changed, and it can also be made r/w.
   
   
2. The element's Access Level is r/w, it is written to the database on save, but the data is displayed to the user as text (non-editable) with a hidden field behind that is submitted to the server. Using javascript the value of this can be changed.
   
   
3. The element's Access Level is r/o, it may or may not be written to the database on save, but the data is displayed to the user as text (non-editable). No value is submitted to the server, and if it is written to the database it will be only a server determined value.
   
   
4. Although option 3. is ideal, it is possible that option 3 is actually implemented in HTML as option 2. and the server ignores the input field value because of the Access Level. This might be necessary e.g. if another calc field is based on this field.

In both cases 1. and 2., we definitely need to run server validation even though the fields are read-only because a hacker could easily changes these fields to any values they want. If the field has Ajax validation set, then I cannot decide whether this makes sense to do or not. Clearly if the field doesn't change, then ajax validation won't run, but if it is changed by javascript and javascript fires the change event, then ajax validation will run - and this probably makes sense.

(Similarly if the field is an ajax calc field it still needs to be calculated on save because a hacker could have overridden an ajax calculation.)

Only in cases and 3. and 4. can we not do any validation.

Now depending on how you made your field read-only will decide which of the above options your field falls into. Did you do it with Access Levels or using e.g. the element's read-only option?

 

[burghard]

It is the third case. The access level is set to RO for the user. But she is not able to store the values to the database she is allowed to, because the RO element does not validate. This comes from the fact that the validator has been created after the value of the element has been changed last time and now has a non validating value.

So it would be nice when the validation does not block if it is RO from the access level and is presented as a RO value.

 

[cheesegrits]

I'm not keen to add that as the default behavior, as it would break backward compat.

But you could do it yourself, by adding a Condition to the validation:

return $this->elementModel->canUse();

... which should return false if they don't have add/edit access.

If that works for you (which it should, I tested it here), maybe you could add a note to the wiki in the validation section.

-- hugh

 

[burghard]

Yes! this does it! Thank you. I documented it in the wiki (see http://fabrikar.com/forums/index.php?wiki/validation-plugins).

 

[cheesegrits]

Thanks!

-- hugh