[Typo3-dev] Re. The future of typo3

[Michael Zedeler]

Daniel Hinderik writes:

>>>   * Sheer volume. There may be thousands of front end users and only a
>>>     few back end users. Finding the back end users becomes difficult.
>>    
>>
>Not the worst of all points.
>  
>
>>>   * Security. Putting the two kinds of users in different tables
>>>     provides extra security.
>>    
>>
>We all know that this is just one paramter.
>
I am happy to see that we do agree on theese two points.

>>>   * Purposes/separation. The two kinds of users will almost never
>>>     overlap and are used for entirely different purposes.
>>    
>>
>That's mostly true in real life business. There are may be less than 5% of
>industries mingling visitors and users, and mostly this setup is really only
>needed because one wishes to downsize the complexity for what would be pure
>editors (=backend users) in specail cases.
>
And then we're back to the purpose of the system. I probably expect it 
to do something that the developers didn't intend to use it for. To me 
it is a special case when the front end users do not "mingle" with the 
back end users.

>>> I don't subscribe to any of theese standpoints. Which ones do you
>>> subscribe to, and have I missed some?
>>    
>>
>I have hoped to argue on a more theoretical level. Revel, I am going to get
>even more airy-fairy now.
>Well you might have missed this:
>
>  
>
>>> 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
>>> records themselves, is much more flexible and extensible.
>>
Yes. I missed it.  The first thing about symbiosis is something that I 
don't really get. I dont think that the two parts should be 
interdependent. (Se the illustration that I posted yesterday.)

With regard to the rest of what you write - I don't see any problem in 
having a system where all user records are extended on demand, 
regardless of what their role (ie. fe/be/other) is. I know that the 
frontend users are more likely to be extended a great deal, but then 
you'll have to ask yourself: do we have a reliable system that handles 
extending the exisiting tables? I think that the answer is "yes", which 
solves the problem.

>Please excuse for now, if I don't provide the bridge between your mode of
>argumentation and mine, but here is my argument restated again in a more
>abstract manner:
>
>In terms of mathematical logic this means, that there are two places in our
>equation eligible for being constants, or being challenged in this sense by
>attaching attributes to either the actors (users) or the objects (records).
>The question is: to which object in our formula do we attach variety, which
>of those is more likely to produce systematically less variety, the frontend
>(to infinty and beyond) or the backend (welcome to Kasper-land).
>
>Sorry to restate the obvious, but for the sake of completing my case:
>The more attributal variety an object theoretically carries, the less it can
>possibly become a constant. If two decriptory types of a semantically shared
>source (the user) differ substantially (!) that is the time to accept a
>fork.
>
>And even more sorry for being so theoretical. I hope it still is
>decypherable.
>
I think I understand. Doesn't it boil down to this: typo3 uses two 
different tables for users because the data there are used for very 
different things?

Clearly there is a real demand for using the two different data types in 
the same context. People have even written modules that tries to close 
the gap - I am referring to the module FEUser->BELogin. 
<http://michael.zedeler.dk/test/typo3-dummy/typo3/mod/tools/em/index.php?CMD%5BimportExtInfo%5D=2072>

I would think it was really nice if I could write a plugin that can be 
plugged in at both sides - in the frontend or the backend, and made 
available to both kinds of users - or one kind if that was my desire.

Robert Lemke writes:

>We had that discussion about roles several times yet. 
>
>Create a backend usergroup and name it "Editors". 
>Create a backend usergroup, name it "Content Editors" and add a sub
>group "Editors".
>Create a backend user being member of "Content Editors".
>
>That's nested roles, isn't it? 
>
Yes. But I haven't found any evidence that groups can be nested in 
typo3. (Please don't answer this question if you feel that you are 
thereby giving me free support!)

>I do say, however, that the user administration must be improved. But
>not by inventing "roles".
>
I think that roles should not be invented as an alternative to the group 
structure already there, but maybe the groups needs a little work so 
that it can easier be used for creating groups. In an earlier post I 
suggested doing something with the typoscript config for the groups that 
are supposed to carry rights like roles do.

>Just a remark to the list above: How would you technically solve the
>problem that Developers are not Main Administrators? 
>
>Basically a developer has the right to create SQL queries so he can
>easily make himself a administrator. Or he could just create an
>extension overriding some functions in the backend.
>
That problem is incredibly hard to solve because it requires a security 
isolation between the core and extensions that I wouldn't know how to 
construct in PHP. It is far easier to just trust the developers. I don't 
know of any cms that provides such a service (but then again, there is a 
lot of cmses out there).

Regards,

Michael.