[#7004] - Problem with edit.state when creating new articles
- Closed
- 7 May 2016
- Medium
- Build: staging
- # 7004
- Diff
- Chraneco:editState
- Success The Travis CI build passed Details
User tests: Successful: Unsuccessful:
Steps to reproduce the issue
- Create a new user group independent from the others
- Give this user group login permissions to the frontend
- Create a new user and assign it to the new user group
- For one content category assign 'create' and 'edit.state' permissions to the new user group
- With the new user log into the frontend and create a new article in the category you gave the 'create' and 'edit.state' permissions to.
Expected result
The new article is saved and already published because the user has 'edit.state' permissions for the selected category.
Actual result
The article is created but it's unpublished.
(That's due to the fact that for new articles Joomla is consulting the root permissions of com_content).
System information (as much as possible)
Joomla! 3.4.1
Solution
The attached pull request fixes this problem by always displaying the 'state' fields if a new article is created, even though Joomla might later detect that 'edit.state' is not allowed. In the latter case JForm will reset the 'state' fields before saving.
Since this approach assumes that valid articles that are going to be saved always have a category ID, this pull request also fixes the bug of being able to submit an article without a category (by tampering with the HTML in the edit form).
Votes
| Labels |
Added:
?
|
||
| Labels |
Added:
?
|
||
| Status | New | ⇒ | Pending |
| Category | ⇒ | ACL |
Yes, in this case the article is saved successfully, but it gets unpublished.
I don't think there is any way around that because we cannot predict in which category the user will create the article.
Shouldn't it work when the author just edits the article a again after it's saved (unpublished)?
It's not ideal, I agree. But showing the state field for people who can't edit it is far less ideal.
I don't think I like the proposed change here.
This is very inconvenient and it works only if the frontend user also has the edit permission, not only edit.state.
True, it's inconvenient. But I don't think it's a good idea to change something for everyone else just because a certain usecase requires some inconvenient workflow. That's not a good way.
If you want to fix this, you need to check if any of the available category for the user allows to edit the state.
It's not only inconvenient, but also impossible if the user does not have the edit permission.
I can fix it by checking the permissions for all categories in the dropdown box, if that overhead is okay for you.
I don't care much the performance impact in an edit form. It's not like that one is requested multiple times per second 
Patch works as described.
| Status | Pending | ⇒ | Ready to Commit |
RTC based on testing
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/7004.
joomla-cms-bot
- | Labels |
Added:
?
|
||
Still don't like this in current form.
| Labels |
Removed:
?
|
||
| Labels |
Added:
?
|
||
| Status | Ready to Commit | ⇒ | Needs Review |
| Labels |
Removed:
?
|
||
| Status | Needs Review | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-05-07 12:46:43 |
| Closed_By | ⇒ | Kubik-Rubik |
@test The effect targeted by the author tested successfully according to the approach described by the author. However, if the user is not autorized to publish for a category, this perpetuates the same 'fraud' which the category field itself gives the user. That is it givves the usr the feeling he can perform actions he is not actually allowed to do. In the case of categories saving in an unauthorized category still gives the user the 'submitted successfully' message.
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/7004.