Previously Sidnei da Silva wrote: > On 4/19/07, Tres Seaver <[EMAIL PROTECTED]> wrote: > >I doubt you would take my patch, which would just rip the whole thing out. > > > >The tradeoff (that users from the root acl_users get a "weird" or even > >broekn experience when browsing in the Plone UI), would be far better > >than stomping the root user folder, IMNSHO: really, that's an "iced tea > >spoon" problem. > > The problem is not just the Plone UI. It affects anyone that uses a > different challenge scheme at the root than at a more internal level. > > And the problem is not just 'broken experience'. You can't login *at > all* with a user from the root user folder on an internal folder, > depending on how you setup your site. That means you can *lock > yourself out*. And not even the emergency user would work IIRC. That's > *as unacceptable* to me as replacing the root user folder.
The emergency user handling in PAS is very robust; I do not see how even a completely broken user folder at a higher level can break that. The main problem for Plone (and other frameworks/applications) is that if the root user folder is not a PAS you can get users objects which do not implemented the IPropertiedUser interface, which may break your expectations. I suspect that the best route forward, at least for Plone, is to just declare that acquisitioned users will work fine in the ZMI, but may not work when you are using the Plone interface. That will allow us to drop the code which replaces the root user folder. > I've repeated this a thousand times now. It only replaces the root > user folder if it's a standard user folder, in which case PAS provides > the *exact* same functionality of the standard user folder, and all > the existing users are kept. It's essentially replacing six by > half-dozen, and I just can't see anything wrong with that. I haven't > seen any good justification of *why* that's a lame idea so far. 'It's > lame because I said it is' doesn't cut it for me. It's an unneeded change to a critical object. If you can get away with not doing that you remove a possible risk of breakage. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. _______________________________________________ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
