Simplify options for setting element visibility

[moofoo]

Right now the following options in element settings can affect visibility:

• Hidden (only for some elements, affects form and detail views)
• Javascript actions (form and detail views)
• Editable (for all elements, affects form view)
• Viewable (for all elements, affects detail and list views)
• Show in list (for all elements, affects list view)

This arrangement is confusing for a couple of reasons:

• The Hidden option can apply to most (if not all) elements, since all it does is apply the 'display:none' css style to the top level container for an element. But, for whatever reason it is only shown for some plugins.
• The Editable and Viewable options relate element visibility to user permission levels, but its unclear whether they also relate to the 'read-only' property that some elements can have, whether they affect plugins like the inline edit list plugin, etc. These things are unclear because 'Editable' and 'Viewable' are ambiguous terms, 'Editable version of element', 'Viewable version of element' are ambiguous concepts.
• The Hidden option and the Editable/Viewable options overlap with respect to form and detail views in some use cases.
• The effect of the different options (how visibility changes) is different - 'Hidden' sets 'display:none' for the top level container of the element, 'Editable and 'Viewable' only seem to hide the input elemen, but not the element's label (in the form view). It's not clear why the differ in this respect.

Here's what I think would be a better solution:

• Move Encrypt data from 'Access tab to somewhere else, maybe add a "Misc" sub-section under the 'Publishing' tab and put it there?
• Remove the 'Hidden' option as a plugin-specific option (remove from field, date, user, internal id, etc).
• Rename 'Access' tab to 'Visibilty'.

In this 'Visibility' tab, replace the current 'Editable' and 'Viewable' options with the following:

1. Link visibility for Form Views. <-- Label
   • Type: Radio buttons
   • Options: No, Yes
   • Default value: Yes
2. Form View - New
   • Type: Dropdown
   • Options: Nobody, Everybody, and the Joomla access levels
   • Default: Set by Fabrik Options
3. Form View - Edit
   • Type, Options, same as option 2 above
   • Default: If the 1st option is set to 'Yes', then this dropdown takes the same value as option 2 ("Form View - New").
4. Details View
   • Type, Options, same as option 2 above
5. List View
   • Type, Options, same as option 2 above

A couple UI details:

• When the 1st option is set to 'Yes', the 3rd option (Form View - Edit) is set to Read Only', and takes whatever value the user chooses for the 2nd option (Form View - New). This is how these settings are by default (how they are for a newly created element).
• If the user changes the first option to 'No', the Form View options are unlinked and the 3rd option stops being Read Only.
• The 1st option doesn't need to be stored in the database - this interactivity described above is just there it's easy for users to replicate the functionality of the 'Hidden' option, which was removed.

This new configuration would cover all the use cases of the current setup, plus some that you can't currently do with just the 'Hidden', 'Editable'/'Viewable' and 'Show in List' options, for example an element could now be hidden from the form view when a record is created, but be visible when the record is edited, or vice versa. This configuration is very easy to understand. In the 'Visibility' tab you can set whether an element is shown or not for each View type, and you can set that absolutely or have it based on the user's access level.

When I'm less busy I'll make a fork Fabrik and work on this myself, however it will be 4-5 months from now before I'll have the free time.

[moofoo]

I can't figure out how to set labels and milestones (I need to be a collaborator I think? I haven't used github in awhile), but I wanted to point out that this is suggestion is somewhere between a feature request and a core change. I'd put it under the someday milestone.

The way element visibility is done now is adequate for almost all use cases.

[cheesegrits]

I agree with a lot of this, and your suggested layout is similar to something I've had in mind for a while.

Much of the inconsistency is due to the gradual development of Fabrik over time, and the various options (or lack thereof) J! itself has provided for access control, starting in the dim distant past with Mambo. Which is why (for instance) certain elements have a 'read only' setting. Which we've ended up keeping for backward compat, but I think now is the time to bite the bullet and get rid of that.

We need to get Rob on board though ...

[pollen8]

Move Encrypt data from 'Access tab to somewhere else, maybe add a "Misc" sub-section under the 'Publishing' tab and put it there?

Note entirely sure what that would gain us

Rename 'Access' tab to 'Visibilty'.

Think i disagree here, generally throughout Joomla this acl controls are labeled 'access'.

Remove the 'Hidden' option as a plugin-specific option (remove from field, date, user, internal id, etc).

I'd agree with this.

Link visibility for Form Views. <-- Label

Could you expand on what this one means?

Options: Nobody, Everybody,

I wouldn't add these in here, its up to the user to create these corresponding acl viewing levels if they so desire.

Form View - Edit

It would be good to come up with some use cases as to where edit acl levels would be different to new acl levels. Considering the large number of acl options we already have for editing a record, would acl on a per element basis when editing a form be needed? I've not seen any examples where this was the case.

I'll set the milestone to this one for someday (think you have to be one of the project admins to do that)

[cheesegrits]

Thinking about it, I think what my issue is, is 'visibility' rather than 'access'.

I'd like to end up with the flexibility to specify if the element is visible:

On new. On edit. On detail view. On list.

As far as Access goes, I'm not sure we need to change anything.

And on a vaguely connected note ... I need to test and confirm whether this is still the case ... one thing I remember having issues with is with elements being used as "approval" flags. I want to set the access so normal users don't have write access ... but last time I tested, this meant that default values weren't being applied. Not sure if this has changed, but IMHO, default values on elements on new forms should be applied, regardless of access. Or at least, that should be an option.

-- hugh

On Tue, Apr 10, 2012 at 6:31 PM, Rob Clayburn reply@reply.github.com wrote:

Move Encrypt data from 'Access tab to somewhere else, maybe add a "Misc" sub-section under the 'Publishing' tab and put it there?

Note entirely sure what that would gain us

Rename 'Access' tab to 'Visibilty'.

Think i disagree here, generally throughout Joomla this acl controls are labeled 'access'.

Remove the 'Hidden' option as a plugin-specific option (remove from field, date, user, internal id, etc).

I'd agree with this.

Link visibility for Form Views. <-- Label Could you expand on what this one means?

Options: Nobody, Everybody, I wouldn't add these in here, its up to the user to create these corresponding acl viewing levels if they so desire.

Form View - Edit It would be good to come up with some use cases as to where edit acl levels would be different to new acl levels. Considering the large number of acl options we already have for editing a record, would acl on a per element basis when editing a form be needed? I've not seen any examples where this was the case.

I'll set the milestone to this one for someday (think you have to be one of the project admins to do that)

---

Reply to this email directly or view it on GitHub: https://github.com/Fabrik/fabrik/issues/220#issuecomment-5058999

[pollen8]

ok so whats the actual difference for a end user between invisible/visible and can/cant access. I think what moofoo is rightly saying is that there isn't really any difference and that we can condense that all down into one set of options which are global for all elements......

Ah yes there is a difference as cant access would still show the data (but in a read only form), hmm so any element really has three possible states

• hidden (if set to yes should basically make the element not editable and not viewable) (Also if set to yes then editable and viewable options not shown as they are not applied)
• editable (fully working field/dropdown etc) applicable in form view
• viewable (if in details view or not edtable then this setting applies)

@moofoo perhaps this is what you meant in your original post?

[cheesegrits]

Well, 'hidden' doesn't necessarily mean "not editable". Like cases where custom JavaScript may want to set the value.

So "visibility" should be separate from "access".

-- hugh

On Tue, Apr 10, 2012 at 7:04 PM, Rob Clayburn reply@reply.github.com wrote:

ok so whats the actual difference for a end user between invisible/visible and can/cant access. I think what moofoo is rightly saying is that there isn't really any difference and that we can condense that all down into one set of options which are global for all elements......

Ah yes there is a difference as cant access would still show the data (but in a read only form), hmm so any element really has three possible states

• hidden (if set to yes should basically make the element not editable and not viewable) (Also if set to yes then editable and viewable options not shown as they are not applied)
• editable (fully working field/dropdown etc) applicable in form view
• viewable (if in details view or not edtable then this setting applies)

@moofoo perhaps this is what you meant in your original post?

---

Reply to this email directly or view it on GitHub: https://github.com/Fabrik/fabrik/issues/220#issuecomment-5059492

[jguice]

Right now I don't see a simple way to have an element hidden yet saved for a public form and visible for a registered/special details view. It sounds like this issue's suggestions would resolve that so +1 ;)

[Sophist-UK]

We need to handle several use cases:

1. Element access insufficient for this user - so element is not even downloaded hidden to the browser (which would be a security risk) - what happens when a record is saved? what happens to calcs based on this field?
2. Element is hidden but in the browser
3. Element is visible.

And choice of 1. - 3. might be wanted by Fabrik access (template type), by Joomla viewlevel (but not through, access), by hidden field option on the element, by menu visibility settings, by javascript etc.

So lots of complexity here.

[jguice]

When a record is saved access should be checked and only fields the user has write permission for should be udpated (I assume it works close to this today or I could construct post data and update fields I didn't get in a form or that were disabled).

Calculations based on the field should use the existing database value (again I assume these happen server-side already). If the field itself is a calculation that should also happen server-side regardless of access (if a user allows a non-public field to be derived from public fields that's a potential programming security issue but not something I'd expect a framework to handle...a warning might be cool though ;) ).

As mature as fabrik is I'm not surprised that it's mostly complex problems that remain :smile_cat: