What makes you think that administrators should be able to see that article?

You'd need to add the administrator group to be able to view guest content. Joomla doesn't set this up by default but with the flexibility in the ACL and view access systems you can do so if desired.

Unless I’m missing something if the admins are added to the guest ACL then they will see the front end guest items when logged in?

Yes, @tonypartridge You are right.

@mbabker If I add the administrator group to be able to view guest content, then the admins will view the guest only content in the frontend. So, we will lose an important feature of Joomla, which is to create content only for not-logged-in users.

@brianteeman The admins should be able to view it in the backend, same as Super Users can. This is important to preserve Joomla's important feature, which is to create content only for not-logged-in users.

You cant have it both ways - if you want someone to be able to edit some content then they have to be able to see it.

I have to disagree with that @brianteeman if the user logged in is a global editor and can do all permissions on com_content they should be able to see all articles as can the Super User.

The query needs to be adjusted to be done by acl opposed to by super user or not.

On 14 Feb 2018, 00:48 +0000, Brian Teeman notifications@github.com, wrote:

You cant have it both ways - if you want someone to be able to edit some content then they have to be able to see it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

I will refer you to one of @mbabker many rants how the superuser permissions are a hack and do not follow the acl

Hehe, if it’s that’s complicated can we not use the same super user hack for the backend? If user is logged into backend show guest items as you would for super users. Since we always know the guest ACL as defined in the config?

On 14 Feb 2018, 00:52 +0000, Brian Teeman notifications@github.com, wrote:

I will refer you to one of @mbabker many rants how the superuser permissions are a hack and do not follow the acl
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

If you look in most code, you basically see if (!$user->authorise('core.admin') { // Add query filter for view access groups here } in almost every place we limit the viewable data based on view access levels. View access levels are unaware of the site's ACL configuration (they don't know what a super user is, or an administrator, or any of the other predefined ACL groups that we ship in core, or can be created by a site owner).

We don't treat view as an ACL action. We apply the view action/permission based on access group configuration. Again, access groups and ACL are two independent systems. So you can have a user group with full permission to something (i.e. our default administrator group in com_content), but they will get restricted as soon as the code hits that $user->authorise('core.admin') check if they aren't in the right access groups.

This is the point where my rant about how access levels should be dropped and make viewing a proper ACL action, dealing with all the repercussions of that decision in the process at some point is repeated.

Short sighted bandaid fixes which bypass security components need to stop being widely proposed and accepted, and proper long term fixes (even if it means we have to retrain users) need to be discussed. The project can't keep sweeping architectural design flaws under the rug, especially when the rug is already 2.47 meters off the ground.

@arbindbhagat

there is already an open issue for this
#17913

@ggppdk OK. Noted.

For me the solution is simple

• have 2 access levels

'access' that we currently have
and
'access_manage'

• if user has either of the 2, then list the record

by having both of the above it will be easy and possible for site administrators to configure the web-site for every use

Now we using the 'access' even when trying to manage the records, and when access levels were original implemented they were only meant to be used for "non-managing" users

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

Closed as duplicate Report #17913

What does having two access levels solve? Nothing, it convolutes the code with more garbage. View is an ACL action. Treat it like one for crying out loud.

The access level system is the hack. That needs to go away. Or, we keep fielding bug reports because the access level system sucks and nobody has the guts to address the root issue.

What does having two access levels solve? Nothing, it convolutes the code with more garbage. View is an ACL action. Treat it like one for crying out loud.

it does solve the problem described above,

• to distiguish viewing from managing !

it is much better than using the single access level for something that originally was not meant to be used, which creates unmanagable records ... unless you make your managers be super admins

it is not "optimal", but it is -simple- and performance wise and it will cover 99.9 % of the scenarios

To add to the solution

after login

• you can have a button to turn-on usage of "access_manage" aka go into managing mode, that is all that is needed

[EDIT]
Display of the manager button (i speak of frontend here) will be done via access level, for backend managing mode will be the default

?‍♂️ ?‍♂️ ?‍♂️

MANAGING IS ALREADY COVERED IN THE ACL SYSTEM!!!

Access levels are a broken concept, do you not understand that? Access levels are a half assed and totally broken implementation of a "view" permission that should exist in the ACL system. Creating ANYTHING new that is supposed to act as an ACL action without integrating into the ACL system IS ANOTHER BROKEN HACK.

Access levels and ACL are two independent systems, and relying on ACL to bypass the access level system is wrong for so many reasons. And your solution is a new access level system to do all of the same broken stuff? Do you not see the problem here?

yes i really agree with everything you said

i understand the issue very well,

i have described the issue here #17913 in details
when some people were saying that there is no problem

so far i have not heard a better solution
in fact noone proposed any solution

about

MANAGING IS ALREADY COVERED IN THE ACL SYSTEM!!!

indeed that is what i expained at #17913
why edit ACL is not used ... and instead access is used ?

because of performance !
it is not performance wise to to use in a 20,000 records view
or not even in a 1000 records view !

i understand the issue, and if you consider the solution i proposed is not good, you can suggest an (implementable) solution, that will not take N years to happen

Also beside performance,
it will be problematic to try to calculate Joomla ACL inside the SQL query, even if we make ACL system "simpler"

Because of how ACL data is stored there isn't a scalable solution that has the same effect of hiding content as the use of access levels does. That doesn't mean the fix should be a new access level solution for only the backend. Or using ACL to bypass access level checks entirely as is done now for super users.

Here's the flaw. In the backend you should be showing all content then using ACL to decide how it's displayed (link to edit, plain text for no edit type stuff). But, because people wanted a way to hide in full some content, the access level filters got applied. If we weren't hiding content we'd be OK.

I agree with Michael that adding a second view level isn't a solution, it just complicates things. The main issue comes indeed from us trying to hide content in the managing context. That was likely a bad decision in hindsight.

However I don't think the idea of access levels itself is flawed. Yes it is an ACL action in theory. But sometimes you need to find a compromise for performance reasons. That is probably the main reason why we still have those access levels: You can't query the db to get a paginated list of items viewable by a given user. Especially since we also have inheritance in our ACL system (from global -> category -> item as well as with usergroups). So we use an own table column for that extracted view action. Imho that compromise is fine from a practical viewpoint and it is also highly flexible (more than an ACL action would be).

Either reopen this, or move your discussion to the issue of ggpdk. It is bad if we just rant for an architectural issue and then we will remember it at the next bug report.
If we truly believe it's a serious issue then put the release blocker tag for 4 and let's address it before waiting another 4-5 years for joomla ?
Sorry for intervening without being capable of actually helping. I just love joomla and your great work for making better. We shouldn't forget that now before joomla 4 beta is a great time to adress these in an even not bc way.

I couldn’t agree more with the above..

On 15 Feb 2018, 09:33 +0000, peteruoi notifications@github.com, wrote:

Either reopen this, or move your discussion to the issue of ggpdk. It is bad if we just rant for an architectural issue and then we will remember it at the next bug report.
If we truly believe it's a serious issue then put the release blocker tag for 4 and let's address it before waiting another 4-5 years for joomla ?
Sorry for intervening without being capable of actually helping. I just love joomla and your great work for making better. We shouldn't forget that now before joomla 4 beta is a great time to adress these in an even not bc way.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.