Bug #61704
closedFilemounts do not show up for Admin users
0%
Description
Filemounts that are assigned directly or that are assigned from groups to an user with "Admin(!)" rights are not shown in the filelist.
How to test:- Create a file mount
- Create a user "Testadmin" and check "Admin(!)" in general tab and Assign the file mount. Save
- Switch or login as Testadmin.
- Open Filelist module (no file mount is shown, only "fileadmin")
- Exit back to main "admin" user
- Create a BE group and assign the file mount
- Edit Testadmin, assign him to the FE group and check "File Mounts" in the "Mount from groups" section (and remove directly assigned file mount)
- Switch or login again as Testadmin
- Open Filelist module (no file mount is shown, only "fileadmin")
Updated by Markus Klein about 10 years ago
- Status changed from New to Needs Feedback
An admin always sees ALL storages, so no need to show filemounts.
Updated by Christian Ludwig about 10 years ago
So does an admin see all db data but still sees db mounts if he/she wants to. This is inconsistent and file mounts where visible for admins in v4.x (I think including 6.0).
What if an non admin gets admin rights, should he suddenly have to learn that all images and files have to be uploaded and selected from other "folders" than he got used to? And when giving a customer a documentation that describes where to put files and images, there must be two different descriptions for admins an non admins?
For admins that do not want to see file mounts or db mounts there is the option to uncheck the setting.
Updated by Markus Klein about 10 years ago
Well, hard to say what is right and what is wrong, but general rule: Never ever do content editing with an admin user! (you're not using root on your machine to surf the web either)
But I'll will not discuss this here. Please move such a discussion to the forum.
Updated by Christian Ludwig about 10 years ago
Feedback was given (an inconsistency in the backend and behaviour change compared to older versions), please change status to "New", "Accepted" or "Rejected". Or help me on what further feedback you need. Thanks.
Updated by Markus Klein about 10 years ago
- Status changed from Needs Feedback to New
Oh sorry, forgot about that. Thanks.
Updated by Mathias Schreiber almost 10 years ago
- Target version set to 7.1 (Cleanup)
- Sprint Focus set to On Location Sprint
Updated by Mathias Schreiber almost 10 years ago
- Category set to File Abstraction Layer (FAL)
Updated by Mathias Schreiber almost 10 years ago
- Status changed from New to In Progress
Updated by Philipp Gampe almost 10 years ago
This behavior was changed for 6.2 on purpose: https://review.typo3.org/29110
Updated by Helmut Hummel almost 10 years ago
- Status changed from In Progress to Needs Feedback
Philipp Gampe wrote:
This behavior was changed for 6.2 on purpose: https://review.typo3.org/29110
The question is if that change made sense. This has to be reviewed and decided by the UX Team
Updated by Felix Kopp almost 10 years ago
- Status changed from Needs Feedback to Closed
- Priority changed from Should have to Won't have this time
- Complexity set to hard
Hey everyone,
thanks for the input and observation!
Yes, there is a valid reasons to not show the file mount.
This should not be changed to the behavior before #57587.
The Admin user has overall privileges (templates, pages, folders, …) those are not limited. Overall privileges lead to full access of the fileadmin folder and all file mouts. All mount points underneath fileadmin can be accessed via the fileadmin folder. Having mount points may lead to easier access to specific files (less clicks) — but brings cluttered entry points (more elements on first level). There seems to be no additional benefit within those additional file mount points on first level.
Also as mentioned before mass editing and file management should not be done ad Admin user. Please change to editor in order to ensure system integrity.
As a last point this additional complexity must be implemented well (better then before #57587) and maintained. After technical review at FAL sprint the time for implementation does not compensate the feature.
Although the previous removal (#57587) had not been discussed in a larger group the solution is good and absolutely valid.
Sorry for closing this discussion.
Updated by Christian Ludwig almost 10 years ago
I am sorry to hear about your decision and started a thread to this feature removal in http://forum.typo3.org/index.php/t/208358/.
Updated by Anja Leichsenring almost 9 years ago
- Sprint Focus deleted (
On Location Sprint)