Issue confirmed.

Hint: Choose in Menu "Create Article" Category "frontend-edits".

System information

3.8.0-beta5-dev
Multilanguage Site
macOS Sierra, 10.12.6
Firefox 55 (64-bit)

MAMP 4.1.1

• PHP 7.0.15
• MySQLi 5.6.35

  ---

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

Thanks for confirming.
As to the hint:
Okay for 1 category, not so okay for a website I manage with 12 separate categories for lots more separate users. By not setting in category in the menu "Create Article" I sort access for al these users into each seperate category out of the 12 used. Really handy.

I looked at this, but the issue is that when the "Create article" view is loaded without a specific category set in the menu items options, Joomla does not know the category you are posting the article in. See https://github.com/joomla/joomla-cms/blob/staging/components/com_content/models/form.php#L124

Depending on the ACL settings this can be 1 specific category, but also 100. So because there is no Category ID yet, Joomla is checking for the core.edit.state permission of com_content, and not a specific category. You can test this by allowing the Edit State action for the Article manager, and then the article will be published when submitted.

There is not an easy fix for this, as it requires to make the frontend submission reloading its data / ajax when changing the category, so the correct permissions are checked.

@sanderpotjer should docs get this Information about choosing a Category or not?

@sanderpotje:
"I looked at this, but the issue is that when the "Create article" view is loaded without a specific category set in the menu items options, Joomla does not know the category you are posting the article in."

Not so, as I wrote earlier: I had this working in Joomla for a period of years!
I am not competent to judge if it will be or won't be "an easy fix". Bit something changed and made it impossible where before it just worked okay.
All I did was create a usergroup and give that permissons for one category: the permissions to Create, Delete, Edit, Edit State and Edit Own.
In the site I developed this became: 15 categories, with permissions set for 20 users.
Worked flawlessly for years.
Now it still works, but articles are only submitted after saving them.
When still logged in the user can see this as a newly submitted article, open it, and click on the publish state to set this from unpublished to published.
So this went form userfriendly and elegant to userunfriendly and ugly.
I would be very sorry if this stays like this. But then again: I am no coder, so if someone tells me this is inevitable. So be it. Still: I do not understand why this impossibility worked so well before al these years.

(If the code cannot be recreated, and this setting will definitely not work anymore, I will create 15 menu items, each for one category, and each viewable for the one usergroup only. This will work, but to me it feels clunky.)

Thank you.

Greetings,
Paul

any Suggestion, @sanderpotjer?

I haven't had time yet to look into this.

Thanks for Info @sanderpotjer

I have the same issue: for years i was able to let users automaticaly post to the one category they had access to. But suddenly (i think since 3.8.0) all categories are listed, and since they are not used to setting the category they post to a category they don't have rights to and get an error

if this is supposed (new) behaviour then there is a backward compatibility issue.

@denniskobus

i think you have (probably) posted into the wrong issue

PR that fixes your issue is already merged (aka will be in J3.8.1)

and it is this
Fix top-level category allowed to be selected for new / existing records, despite disallowed via ACL core.create #18131

Also fix is included in J3.8.1-rc
https://github.com/joomla/joomla-cms/releases

you can test J3.8.1-rc in testing website

I think you are right. Great that there is already a solution!

thanks,
Dennis

Op 02-10-17 om 14:51 schreef Georgios Papadakis:

@denniskobus https://github.com/denniskobus

i think you have (probably) posted into the wrong issue

PR that fixes your issue is already merged (aka will be in J3.8.1)

and it is this
/Fix top-level category allowed to be selected for new / existing
records, despite disallowed via ACL core.create/ #18131
#18131

Also fix is included in J3.8.1-rc
https://github.com/joomla/joomla-cms/releases

you can test J3.8.1-rc in testing website

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#17812 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/Ae86-spbPO7pdwMvvn-eT5cZzksVcQG_ks5soNxrgaJpZM4PJitl.

Should this issue be closed? Since we have J!3.8.5 in the wild... ;)

@onderzoekspraktijk is this Issue solved so it can be closed?

Thanks @pepperstreet.

On 10/03/2018 20:37, Franz Wohlkönig wrote:

@onderzoekspraktijk https://github.com/onderzoekspraktijk is this
Issue solved so it can be closed?

Thanks @pepperstreet https://github.com/pepperstreet.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#17812 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJ0G3qN-qVP-xKkFUte3UCroyBzIzDpiks5tdCtggaJpZM4PJitl.

I wil check this the coming days and report what I found.

Just now checked this on an joomla 3.8.5 site: the 'new' behaviour is stiil there: no change since this was reported on sept 1, 2017.

thanks for Info @onderzoekspraktijk

Should this issue be closed? Since we have J!3.8.5 in the wild... ;)

@pepperstreet so this Issue can't be closed.

Just read a post about a similar issue in the Joomla! CMS Development goup: Administrator Link To Edit Article With Pre~Selected Category
(https://groups.google.com/forum/#!topic/joomla-dev-cms/HR79lu-4-AQ) .
There Randy Carey reports a change in behavior that was present up through 3.1.x, "but (inadverantly) removed in 3.2 with code that changed how input parameters store the filter settings. I wrote this plugin to restore this behavior, as I depend upon this behavior to give clients dashboard links to pages with preset filters."

This bug torment joomla users for couple years now.

@onderzoekspraktijk can you share your joomla bug fix submit pull request to fix this big joomla issue?

Or maybe other joomla developer have better solution to solve this joomla 3.9.10 bug issue?

Joomla users are very dissapointed to not beeing able to see their joomla article.

I confirm Joomla 3.9.10 bug in frontend created articles are not published but only submitted.

"@onderzoekspraktijk can you share your joomla bug fix submit pull request to fix this big joomla issue?"

Sadly I do not have a bug fix to submit: writing one is beyong me level of competence.
I did report a a post by Randy Carey in which he told he wrote a plugin that solved a comparable issue. This plugin however does not solve the issue I reported.

Its big joomla bug and joomla 3.9.10 backward compatibility issue

So no one have created joomla bug fix to submit and test?

Sadly no one from joomla core dev team is trying to solve this joomla 3.9.10 backward compatibility issue

Its very interesting why joomla 3.9.10 users can't from frontend create articles and publish but only can submit? But in older joomla 3 versions they could do that.

Joomla core dev team do not keep and is in breach of their promisse to keep joomla 3 backward compatibility or .... ?

@onderzoekspraktijk Please state the exact version of Joomla where you consider it was working fine and I will have a look.

it seems before Joomla 3.5.7 as stated by @onderzoekspraktijk on the op

It is unrelated to #25757

This issue still don't have a fix?
I'm using 3.9.22 and even with my Super User account, when creating article in front end, the article only get submitted and I receive a back end message, but I have to go to the article list in back end to publish manually the articles.
I'm confused that there no way that the articles created in front end are automatically published anymore...

PR #32117 should fix this issue, too

Closing as having a pull request. Please test #32470 . Thanks in advance.