UI fix: user with authorization to create in at least a category can access editor view in menuitems for other categories

[LivioCavallo]

Summary of Changes

Perform an additional authorization check at the category level in com_content edit view file: view.html.php .
This blocks an unauthorized user from accessing the editor in some circumstancies when he does not have "Create" permissions for that category.

Testing Instructions

Create a new User Group: "Manage Category ONE" with 'Public' parent group.
In System / Global Configuration set Permission to allow "Manage Category ONE" group to Login into site.
Create new user 'User1' as member of this group.
Create a new article category "ONE" and set permissions so that "Manage Category ONE" group is allowed to "Create".
Create a new article category "TOP SECRET" and check that "Manage Category ONE" group has no permissions to "Create" in it.
Now create a menuitem, "Create Top Secret", to submit a new article; set Options so that default category "TOP SECRET" is default.

Login as "User1" into frontend and "Create Top Secret".

Expected result

User is not authorized, not having rights to "Create" in "Top Secret" category.

Actual result

User is allowed to enter the editor! He can even browse images folder.

Notes

In J!3.4.4 (and I suppose in some later versions) the user was allowed to save the article!
In J!3.7.5 (I suppose starting from some previous versions) when he clicks on "Save" the operation is blocked with error; this mitigates the problem.
Anyway I think that accessing the editor (though the most dangerous functionalities are disabled) is not a "good thing": the user should be blocked as soon as he tries to access a resource he is not authorized to use, not later, when he tries to close (save) that resource.

[ggppdk]

Is there a reason you are using $app->getMenu()->getActive()->params ?
For consistency you should use the $this->state->params to get 'catid'
e.g. in the line above you are using it to get 'enable_category' which is also a menu item parameter

[LivioCavallo]

No.
Right.

[ggppdk]

Also i noticed that parameter name is 'Default category'
but parameter description says:

If set to 'Yes', this page will only let you create articles in the category selected below.

so "Default category" does not sound like best choice
instead of "Default category" a proper parameter name would be

• Limit category
• Category Limitation
• Specific category

---

[LivioCavallo]

Constrained / Bound category?

[Quy]

Sort alpha order. Swap lines 33 and 34.

[LivioCavallo]

Oooops. Tks

[infograf768]

Constrained is hard to translate.
"Specific category" reads better imho.

[ggppdk]

This is more an UX fix , that an security fix (e.g. the form display of custom fields of an non-accessible category are revealed),

i say UX because, imagine someone spending 10, 20 minutes to fill in the form and then clicking save, to discover that has no access to save the form, some real frustration

[LivioCavallo]

So should I change name to: "UX fix: ..." ?
(Or programmer safety? 😉 )

[infograf768]

Hmm, found a bug, unrelated to this PR.
One can save a Create Article menu item, settting "Default Category" to Yes and NOT filling the "Choose a Category" field.
In frontend, using such a setting forces to save the article created in the category with the smallest Id. catid param is therefore empty.

Therefore I suggest to use

$catid = $this->state->params->get('catid');
if (!empty($catid)
{
   $authorised = $user->authorise('core.create', 'com_content.category.' . $catid);
etc.

as I could not find a way to solve that bug.

[LivioCavallo]

Oh! Thanks. Fixed.

There is a way to add client-side field validation to params form field in backend?
In this case it would be useful something like 'showon:', let's say 'requireon:'.

[LivioCavallo]

It seems there were problems with drone and appveyor, but I don't find a way to restart them. Is it normal?
Or there is really any error?

[alikon]

i think we still need to manage properly the issue referenced by @infograf768, your fix just show Error save not permitted but maybe is better to open a different issue for that

[alikon]

I have tested this item ✅ successfully on 175a328

as per pr testing info

---

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

[LivioCavallo]

You are right @alikon.
Now we have a new issue: #17708.

[ggppdk]

@LivioCavallo

I have made PRs against you patching both places, that 'enable_category' is used

components/com_content/views/form/view.html.php
and
components/com_content/models/form.php

now code will work properly even if user has set 'enable_category' to YES and did not select category

• it will now behave as if 'enable_category' is NO

fixing is #17708 is now not needed

[LivioCavallo]

Why is AppVeyor failing?

[LivioCavallo]

I tested it in Jommla! 3.7.4, 3.7.5 and 3.8 beta. This patch works as expected.
Did someone else test it?

[infograf768]

I have tested this item ✅ successfully on ad148a7

---

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

[ghost]

@alikon can you please retest?

[alikon]

I have tested this item ✅ successfully on ad148a7

---

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

[ghost]

Status "Ready To Commit".

[richard67]

@HLeithner What happens with this PR?

[HLeithner]

Something take longer then other, thanks for this PR