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

Constrained / Bound category?

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

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

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

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.

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:'.

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?

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

I have tested this item ✅ successfully on 175a328

as per pr testing info

I have tested this item ✅ successfully on 175a328

as per pr testing info

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

@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

Thanks @ggppdk, I like your idea, I think it's a good workaround. I merged it.
Anyway I think that the "Selected category" should be 'required' if Default category is ON and the user should be blocked on saving or at least receive an alert saying that without selecting a category there won't be any constraints on the category, as if 'enable_category' is OFF, as implemented by your PRs.
I think that issue #17708 is still needed.

I think that issue #17708 is still needed.

Agree, but can be done separately. (requiredon is not a simple task to implement)

@infograf768 : I agree. This PR fixes problems. Thanks all.
A better Long term user experience will be eventually provided by #17708

Why is AppVeyor failing?

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?

I have tested this item ✅ successfully on ad148a7

@alikon can you please retest?

I have tested this item ✅ successfully on ad148a7

Status "Ready To Commit".

@HLeithner What happens with this PR?

Something take longer then other, thanks for this PR