Project

General

Profile

Actions

Feature #14552

closed

Backend usergroup module enhanced (full blown)

Added by Georg Rehfeld almost 20 years ago. Updated over 18 years ago.

Status:
Closed
Priority:
Should have
Category:
Backend API
Target version:
-
Start date:
2005-02-15
Due date:
% Done:

0%

Estimated time:
PHP Version:
Tags:
Complexity:
Sprint Focus:

Description

while entering german Context Sensitive Help (CSH) text for the backend user group module I came across this:

- the list in 'allowed excludefields' is extremly long.
- everyone knows to have to hold down CTRL while clicking in the field ... but if one had made several unsaved modifications and then clicks without CTRL by accident, all work is lost immediately, the only fallback is to leave editing mode without saving and start over
- although 90% of the choices may be familiar to most admins the rest of them (and for newbies even more) aint' too obvious and need explanation
- some of the entries (look near the end of the list) are far too wide to be read completely

So I suggest:

have this list box changed to (sort of) an unordered list or some tree. Level 1 would be the table at hand, level 2 the field and a checkbox to en/disable access.

This could be done either the usual way by reloading the page (after saving intermediate changes) when a folder open/close icon is clicked or, maybe, M$ way, delivering all settings and folding done via EcmaScript. I preferr reload, as it at the same time saves intermediate changes implicitely and only delivers visible/worked on content.

This would also enable the possibility, to have a CSH icon for every field, that pops up the CSH already existing for the corresponding field. Even the CSH .description field might be shown by default, eventually shortened to some number of characters.

If the module would also remember the open/close state of the tree nodes, as e.g. the "TypoScript Object Browser" does (and additionally offer a choice to open/close all nodes) admins could make their way through this configuration much more easily, eventually distributed over several sessions, and learning a lot about Typo3 on their way.

Also, the strange name "allowed excludefields" (Erlaubte Ausnahmefelder??? ... Ausdrücklich erlaubte Felder???) could be changed to something more meaningfull, if all fields would be listed for every table, with a checkbox initially having the allowed/disallowed state as defined by the core/extension. Then, fields, that are requiered (e.g. "uid", "pid" etc.) should be shown checked and disabled ... but still shown as existent in the table! Also, I would like to have the raw DB field name in parens or so besides the translated name.

The latter would make the "Explicitly allow/deny field values" list obsolete also, maybe, these fields should be marked somehow as important (different color?, but still enabled to be disabled :-) ).

The title for the list would be simply "allowed DB fields" (Erlaubte DB Felder).

And this also would turn the module into a great reference of all existing database tables/fields, easily to be used by anyone making extensions or having to write TS with direct access to the DB, e.g. "{page:title}".

And, maybe, even the 2 listboxes "Tables (modify)" and "Tables (listing)" could be eliminated at the same time and the backend group administration made even more streamlined?

Would require 2 more settings per table, "allow listing" and "allow modification". Note, that all fields still should be listed for the table at hand, disabled, when "allow modification" is turned off ... to not break the 'reference' feature.

This would solve the issue, that in "allowed excludefields" there are fields of tables listed the group members don't have access to anyway.

What do you think?

regards, Georg

compare developer thread at:

http://typo3.org/documentation/mailing-lists/dev-list-archive/thread/110110147/?tx_maillisttofaq_pi1%5Bmode%5D=1
(issue imported from #M790)

Actions

Also available in: Atom PDF