[Typo3-dev] The future of typo3

[Daniel Hinderink [TYPO3]]

Hi,

Here is a point that I would like to comment independently of my overall
reply.

>> Another example would be any website using heavy user interaction with many
>> levels of permissions (or roles), such as an information portal, an intranet,
>> extranet or the like.
>> In those cases, you have to either let the users straight into the backend
>> when 
>> editing something or doing it all ground up.
> 
> That is a good point to discuss. I'd like to add more questions:
> 
> - How about a new type of user which is allowed to create backend users
> but is not administrator himself (i.e. without access to TS templates)?

I am screaming NO PLEASE NOT here.
The backend user concept is a major problem as it is already. Please don't
even think about adding more static pre-built roles, the admin/user
dichotomy is already a most hampering limitation to create real life
useability.

What we need is a completely modular and configurable user concept, at least
for the backend:

- all aspects of the backend editing options need to be controllable from
the group and user settings. Currently content types and the "backend menu"
and it's items is not.
- every default backend application, like the template editing suite needs
to be changed, so that they can be configured for every user and group.
A use case for this would be a limited-range admin (in the
user/admin/dev-paradigm) who would be limited to editing a template only in
his file mount and only through the constants editor.


> - What about a new user administration module which can easily handle
> 1000+ (backend / frontend) users?

At this point it is not a matter of building new features, but cleaning up
the existing functionality according to the use cases that we now know
about.
The problem is that noone likes to clean up, instead of creating something
new from the ground up.

On the general notion of creating a symbiotic frontend and backend user
concept, I am less enthusiastic about this.
The main reason is that the backend users and groups will have some fairly
static range of settings to make, basically the ones we have today, plus
backend menu and settings thereof and of course content types.

The frontend users logic is different: users might have access, own a record
or some other association with a function or a record, but the form and
content will vary most widely.
Therefore the rather thin definition of the FE-User (basically the id) and
the notion of attaching information about rights and ownerships to the
records themselves, is much more flexible and extensible.

On a more systematic scale, I believe calling for unification on the grounds
that frontend interaction is as important as backend interaction today, is
too superficial.

>From looking at other systems and also the landscape of online publishing, I
rather believe, that the process of publishing becomes ever more integrated
with backend systems, like DMS-solutions, or is even replacing the backend
entirely with applications in a single-source scenario.

The frontend interaction of some business value today, is not so much
content creation, but CRM and eBusiness processes. These are mostly
implemented on the basis of application servers, because of their uniformity
and performance critical nature.

Summarising these two "worlds" will not, in my opinion, mean a more uniform,
but a more open approach. Practically speaking, it is important to go the
way Robert and René have indicated, of making (existing) functionality more
reusable on all ends of the system.
That does not mean that online publishing, like blogs and wikis might make
you think, ask for the integration of these two concepts of backends and
frontends per se.

We have an Architecture-Team for this. How about some light, lads :-)

Cheers,

Daniel



-- 
TYPO3 - get.content.right

Daniel Hinderink
Marketing, Press Relations, Strategy
http://www.typo3.com