• Hello Fabrik Community

    Fabrik is now in the hands of the development team that brought you Fabrik for Joomla 4. We have recently transitioned the Fabrik site over to a new server and are busy trying to clean it up. We have upgraded the site to Joomla 4 and are running the latest version of Fabrik 4. We have also upgraded the Xenforo forum software to the latest version. Many of the widgets you might have been used to on the forum are no longer operational, many abandoned by the developers. We hope to bring back some of the important ones as we have time.

    Exciting times to be sure.

    The Fabrik 4.0 Official release is now available. In addition, the Fabrik codebase is now available in a public repository. See the notices about these in the announcements section

    We wish to shout out a very big Thank You to all of you who have made donations. They have really helped. But we can always use more...wink..wink..

    Also a big Thank You to those of you who have been assisting others in the forum. This takes a very big burden off of us as we work on bugs, the website and the future of Fabrik.

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

burghard

Member
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.
 
@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?
 
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.
 
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:

Code:
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
 
We are in need of some funding.
More details.

Thank you.

Members online

Back
Top