Bug #25433
closed
Pagetree drag and drop - should be disabled when user can not edit "pages"
100%
Description
I have a usergroup that has page types Standard and Shortcut allowed, but only to localize pages. They may list "pages" but not edit them. -> can not create new pages -> toolbar to create pages with drag and drop should not be shown as well as the delete dropzone or even better DD should be deactivated completely.
When i try to create a new page that way (without permission), i get a JS error in IE8:
Zeile: 46
Fehler: 'TYPO3.Flashmessage' ist Null oder kein Objekt
Firefox shows me the Flashmessage: Exception
[1.2.1]: Attempt to modify table '%s' without permission
This is somehow related to #25183, because in both cases DD needs to be deactivated.
Files
Updated by Susanne Moog over 13 years ago
- Category changed from Backend User Interface to Pagetree
Updated by Felix Kopp almost 13 years ago
Current user must have the privilege to delete the to be dragged page
Updated by Andreas Kießling almost 13 years ago
Felix Kopp wrote:
Current user must have the privilege to delete the to be dragged page
Maybe i can restructure the backend groups, but this makes the whole setup more complex.
A check if page records may be edited at all should not be too difficult.
With the default access module, you can only set the permissions for one user/group and all.
Otherwise you need be_acl which used to be quite "expensive". That's why i put all users in a "default" group. The ones with modify rights for pages can create/delete, the others just list. (There are more backend users that also see parts of the pagetree, so "all" is not really an option)
I did a short test in IE9 and i may drag the pages to the delete zone, but no error pops up there.
After dragging in a new page, "Please wait ..." in the tree just waits for some response from the server.
Updated by Philipp Gampe over 11 years ago
- Status changed from New to Accepted
- Complexity set to medium
All edit features of the page tree should be deactivated if a user does not have write permissions for the "page" table.
This is a bit harder if you want to do this on page level (access check). Nevertheless, it should be doable.
Updated by Mathias Schreiber almost 10 years ago
- Target version set to 7.4 (Backend)
- Is Regression set to No
Updated by Susanne Moog over 9 years ago
- Target version changed from 7.4 (Backend) to 7.5
Updated by Benni Mack almost 8 years ago
- Target version changed from 8 LTS to 9.0
Updated by Riccardo De Contardi almost 7 years ago
I performed a test with 8.7.9
Prerequisites¶
- backend user without admin privileges
- backend usergroup for that user
- backend usergroup > edit > ACL > Tables (modify): I removed "pages".
Results¶
Page Module and List module: the edit icon is still visible but clicking it leads to infinite loading circle. I discovered that this behavior comes out because in the Access Module, the pages still have "edit page" checked on both user and usergroup.
After I also removed "edit pages" from the access module to both user and usergroup:
- the edit icon in page and list module is no more present
- drag and drop from the top of pagetree: still present, but leads to error:
1.2.1 Attempt to modify table 'pages' without permission (see attached file)
- trying to move page with drag and drop:
same error
- trying to delete the page dragging it to the delete area:
same error
Updated by Gerrit Code Review almost 5 years ago
- Status changed from Accepted to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/63514
Updated by Gerrit Code Review almost 5 years ago
Patch set 1 for branch 9.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/63463
Updated by Christian Eßl almost 5 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 953cb02f9e20f3c79c0641702955b4436fa64a98.
Updated by Benni Mack almost 5 years ago
- Status changed from Resolved to Closed