[4.0] [RFC] Viewing access levels inconsistently mixed with create / edit ACL

[ggppdk]

Steps to reproduce the issue

An article A or a category A or some other record A
-- should be viewable by usergroup A (most common use case is guests)

The above mention article A or a category A or some other record A
-- should be editable by usergroup B (NON-super user)

Expected result

Possible

Actual result

Not possible

And to make it worst it is possible via direct links because
-- e.g the article manager will not list a non-viewable article to non-super admins but if you type the edit link in the browser e.g.

administrator/index.php?option=com_content&task=article.edit&id=2

then you can edit (if of course you have edit ACL on the article)

System information (as much as possible)

All versions

Additional comments

Whey was this done ?
initially viewing access levels were for viewing only,

then in J1.6 / J1.7 it was expensive to calculate edit ACL so access level on article's categories were used as work around for listing articles, and later consideration of access levels of the articles was added too

As mentioned above most common use for having non-viewable articles / records would be articles meant to be shown to guests, but then we need some editors,

so a hack was added

• the super admin can list these articles,
• but this hack does not apply to other editors

Inconsistencies about the whole thing

• why consider viewing access levels for not listing items that the managers / administrators can Edit / Publish / Delete ?
• language strings for create ACL / publish / edit ACL mention nothing about viewing access levels
• a false message is given to the users that if a record is not listable the it is not editable or publihsable or deleteable by the user groups that cannot list it , but of course none of the inner ACL checks is checking viewing access levels
• UX is problematic you can not have editor editing articles / records that should only be shown to specific usergroups

another example is the category selector for create articles

Expected (sane) way to populate the selector

• add categories that user can create articles in them, right !!! ???
• then for categories that there is no privilege then check viewing access level, if category also not viewable then hide category, if category viewable then show it as disabled

[ggppdk]

The most common usage issue (95%), has been addressed with a hack

• super user can list articles / categories with guest access level, thus they can easiy edit them

Still maybe something better can be done in J4

[brianteeman]

you are confusing access levels and viewing levels. they are two different things

[ggppdk]

There is only 1 type, we do not have 2

[ggppdk]

@brianteeman
Only 1 DB table "viewlevels", maybe you can explain in more detail ?

[Bakual]

Main question to me is how an editor is supposed to check the article (in frontend) if he isn't allowed to see it. Imho it just doesn't make any sense to allow editing an item which you're not allowed to see.
The only case I can see where this makes sense is the "Guest" usergroup, and the issue probably arose there. But then, the "Guest" usergroup is actually a bit of a hack.

You can't have the list based on ACL (edit) checks. You need something which you can query with the database, and calculating edit (and edit.own) rights with all its fallbacks to component/global and category levels just can't be done with SQL.
So you'd need two viewlevels, one for backend and one for frontend. But honestly that just complicates things and in the end all you want is to edit items assigned to "Guest".

There is a much easier solution to that, just allow those who have to edit the items to actually see it. Eg let them see the "Guest" articles as well when they're logged in.

[ggppdk]

The only case I can see where this makes sense is the "Guest" usergroup, and the issue probably arose there. But then, the "Guest" usergroup is actually a bit of a hack.

That is the most common case, but you can have some sites that need to show content only to specific groups,

• with the current design the editors of this content must also have the access level of the content

besides the above thing i described other issues in my initial posting

[brianteeman]

from @chrisdavenport joomla/user-interface-text#11 (comment)

Access levels are the hierarchical levels that determine what a user can do (eg. configure, create, update, delete and other tasks including custom ones). "Viewing access levels" only determine what a user can see.

A user can belong to one or more user groups and one or more user groups can be assigned to a "viewing access level" (although it's really a group rather than a level, because the "levels" don't form a hierarchy). User groups can also be assigned "access level" permissions (which do form a hierarchy since the permissions follow the user group hierarchy).

So, you can change the "view level" of an article, say, by going into the article screen in the Article Manager and changing the "Access" drop-down on the right-hand side. That determines which user groups can see the article. You change the "access level" for articles by going into Article Manager -> Options -> Permissions where you can assign "Actions" to different user groups. That determines which user groups can do things such as create or delete articles. So "view levels" and "access levels" are quite distinct, although they are tied together by user groups.

Confused yet?

[Bakual]

besides the above thing i described other issues in my initial posting

Same applies there. You can't have a list based on edit permissions since you can't query that. You would have to load the full list and then do an ACL check on each entry. That's certainly not something you want to do.

So your only option is to add another "access" column to the database where you can specify a backend viewlevel, because that is actually what you request. So you can specify different viewlevels for backend and frontend. But as said that just complicates things imho.

[ggppdk]

@brianteeman
I have simply added "viewing" in front of "access level" to my original description
i changed nothing else

Now nobody reading it should be confused
also when i was using "access levels" as shorter name for "viewing access levels",

• since Joomla menu and some language strings do this, so i thought that nobody reading my description will be confused

I guess the
"Separate ACL for Viewing and Doing"

mentioned here:
https://docs.joomla.org/J3.x:Access_Control_List_Tutorial

is no longer applicable, now they are mixed

[brianteeman]

Sorry I just dont agree that anything has changed with the ACL since those docs

That will be my last comment

[ggppdk]

That will be my last comment

ok sure this is an RFC

Sorry I just dont agree that anything has changed with the ACL since those docs

about changes i meant PR like this:
#12931

[ggppdk]

@Bakual

See comments by 4 other users / contributors here, saying some of the issues mentioned above

#7775

comments by: by @izharaazmi , @renekreijveld, @Ruud68

e.g. izharaazmi comment

Only guest can VIEW the content is not same as only guest can MANAGE the content.
only administrator can MANAGE the content is not same as Only administrator can see the content

and yes guest level is most common case, but same can apply to other view levels (rare usage cases in some sites)

[ggppdk]

There is a simple solution, let this be configurable for backend

[ggppdk]

@Bakual @mbabker

Regardless of how this is implemented,
regardless of details of access level implementation
and regardless of details of ACL implementation

especially for frontend (but maybe for backend too)
there should be possibility to have 2 modes

• normal mode
• management mode

the contents for each mode should be different

• things i should be seeing and are "active" (published not expired)
• things i am allowed to manage

e.g. at frontend after login
as administrator i should not be asked to buy subscription but i should be able to edit it when i need to

e.g. at frontend after login
i should be able to have a view that only lists what is published / not expired / accessible according to my access level, etc
but as owner or administrator i should be able to switch to a view to manage my articles or articles or modules etc i can edit

i mean the source of the problem is that these 2 modes are mixed

[mbabker]

The "normal" mode you speak of is view permissions.

There should be no concept of a "management" mode that displays different content on a loaded page by way of a different system. Change your existing access levels if you really want to do this and stop relying on the default "Public/Registered/Special/Guest" configuration to just work for every possible use case out of the box.

Either way, we need to stop doing stuff like this which effectively bypasses access level group restrictions for super users, or liberally using the same concept to do the same for other core permission levels. User::getAuthorisedGroups() should in effect report that a super user is part of all user groups (and inherently access levels).

[joomla-cms-bot]

Set to "closed" on behalf of @jwaisner by The JTracker Application at issues.joomla.org/joomla-cms/17913

[jwaisner]

Closing this as it has been inactive and based on comments not a directional change to be done at this time.

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/17913.}