Jim, Phillip has an idea that could make life simpler for Zope newbies. This would be intended for the next major Zope release. "Phillip J. Eby" wrote:
Well, I'm hoping you'll take a look at my Collector suggestion for a new Zope feature. :) Specifically, extending the "access" file to allow other "top-level" users to exist besides the superuser, who have roles defined in the file. There are many ways this would be useful, not the least of which is to break the "you need to do that at the next level up" problem. (Others include a simplified process for getting your Zope site set up, since you then don't have to login as superuser and add a user folder, then log back in as somebody else.)
If this were done, we could easily go to letting LoginManager objects be owned, since there'd always be a place "above" the LoginManager for the owner user to reside.
Hmm... this sounds like a good idea, but now that the ownership problem has been resolved in a way I didn't expect, the issue that motivated your idea is gone.
Maybe, maybe not. I think perhaps the most compelling argument from Digital Creations' viewpoint for having an expanded "access" file might be the simplification of the setup process for customers. And it would also make it easier to:
1) Phase out unownedness (user databases wouldn't need it) 2) Narrow the role of superuser (super-can-create hack can go away) 3) Do Zope virtual hosting and give somebody a Zope root and even superuser, while still being able to log in 4) Stop all the whining from people who want to know why superuser can't create or own objects any more. :)
As I understand it, the reason we needed to revoke capabilities from the superuser was to ensure there was someone who could be assigned ownership for every object. Do you think an expanded access file, which would include multiple users and role lists, would enable us to reduce the magnitude of the SuperCannotOwn dilemma? Perhaps during installation the user would set up two user accounts, a superuser and a normal user. Shane