[Typo3-dev] Re: The future of typo3

[Didier Geheniau]

> -----Original Message-----
> From: typo3-dev-bounces at lists.netfielders.de 
> [mailto:typo3-dev-bounces at lists.netfielders.de] On Behalf Of 
> Daniel Hinderink [TYPO3]
> Sent: maandag 27 oktober 2003 8:48
> To: List for Core-/Extension development
> Subject: Re: [Typo3-dev] Re: The future of typo3
> 
> 
> >> That is probably right for content creation from an internal user 
> >> base, kept in Active Directory/eDirectory/LDAP. But 
> frontend users in 
> >> real life business cases don't exist in the formats 
> mentioned above. 
> >> They are kept in specialised CRM-systematics. There is simply no 
> >> business case to speak of and on top of that a structural problem 
> >> witn integrating these two tables. In fact, I see no advantage to 
> >> speak of in any of your (plural) explanations.
> > 
> > It does not matter weather they exist on what system, the 
> same person 
> > can still be accessing the front and back-end.
> 
> Please reread my paragraph above.
> 
> >Personally I think
> > general user information should be kept in a LDAP like system so it 
> >can  easily accessed by other systems. A CRM system is something 
> >completely  deferent then an Active Directory,eDirectory or 
> other LDAP. 
> >Also a  CRM-system can make use of LDAP. But that discussion 
> goes on an 
> >other  level I think.
> 
> ? What I am saying is, that the role accessing the front and 
> backend has no business case to speak of. I also explain why. 
> The reason is that serious frontend functionality is not 
> implemented by CMS's but rather wraps them. Small scale 
> frontend functionality, like we have in TYPO3, simply doesn't 
> demand a unified user system.
> 
> May be it is time to restate what TYPO3 is not: it is neither 
> a portal system, nor an application server. It is a CMS with 
> some functionality in these two areas, but it focusses on 
> managing and publishing content. That is where our main market is.
> 
> > 
> > 
> >>> Personal user settings
> >>> can be stored in typo3. No authorization information must
> >> be stored in
> >>> a user record, store this information in the group records.
> >> 
> >> It doesn't work for content creation beyond simple setups and any 
> >> major vendor (coremedia, vignette ...) is not following this path.
> > 
> > That they doesn't follow this path might not be that it is not the 
> > right path, but when they choose this path they did not see 
> an other 
> > way.
> 
> Are you serious?
> 
> > Company choose systems for strategically reasons. And the best 
> > solution is not the only strategy. I see many companies 
> choosing for 
> > systems because of other reasons then the best solutions!
> 
> Sad but true :-)
> 
> > 
> > Typo3 is a general system, and I hope not mentioned for 
> just one ore 
> > to companies and/or branches!
> 
> Above all it is a CMS.
> 
> >Separation of front-end and back-end must not
> > be based on the techniques! You can implement one method 
> where user  
> >management (not the authorization, only the authentication) is done 
> >with  the same method. Splitting physical storage location 
> of front-end 
> >and  back-end users can always be realised by an extra option and 
> >remaining  usage of the same technique!.
> 
> Again, that is not what I was questioning.
> 
> > 
> > By using defend techniques for frond-end, back-end usage u 
> choose by 
> > design that it is impossible to merge them!
> 
> Why should we? Noone ever answered this with a business case.

I Answer it now then:

Whe have a large de-centrelized organization who wants to make use of
the same system. Users are kept in a LDAP environment and may only be
stored there because they want user management on a single location.

So more websites are managed on one instance of typo3. Every website can
have a secure area for private information.
A user can be the maintainer for one website and have rights for a
private area of an other website! More then one user record is in this
case out of the question!

Because they have a an own session management for single logon I had to
reprograme the backend for this so I also changed the user part.
Unfortunatly I can not donate the code because our customer does not
allouw us to because of their session management. But I can always
advice ;).

Regards,

Didier