At 10:54 AM 7/25/00 -0400, Brian Lloyd wrote:

I think that this is _definitely_ the kind of thing that should be done in the fishbowl on dev.zope.org. Why? Because while it may be a "minor patch" in terms of lines of code, just applying the patch causes a number of problems that have nothing to do with software per se.

Sorry about that. As you may have seen from the list, I did enquire as to whether this should go in the fishbowl, and was told that such a minor patch probably didn't need it. I thought the issue was more complex than it was also; I was under the impression that Zope had a user folder *above* the official "root", not realizing that it was merely that the "physical root" had a default user folder in existence.

What is the problem being solved? How exactly does this solve it? Is it the right solution? Why did we make the decisions we made? Of course some discussion of these has occurred on the dev list, but the only way I (or anyone else) can discover these is to piece things together by searching list archives.

Problem being solved: the new ownership model requires a place for ownership to "bottom out" so that user databases themselves can have owners. The previous solution was the creatable-by-super hack, which only created further holes in the ownership model, since user databases which involved components which followed the security model (e.g. GenericUserFolder and LoginManager) then had to suppress ownership characteristics or else be unusable as a root-level user database. Second problem: the initial existence of only a single Zope user who could not actually do anything except create a UserFolder, was troubling to new users of Zope and at best inconvenient for experienced ones.

o There is no visibility of the impacts of the change.

How does this affect ownership? Does this work with all existing user folder objects, or do they all need to change to support it?

* The "rootUsers" can own things * They appear to be normal members of the root UserFolder, except that they do not appear in its contents as they are not stored there. * It is not necessary for a user database to support the rootUsers; however if the top-level user database of a Zope installation does not support them, they will not be usable in that installation. * User databases using the existing name==super.getUserName() protocol are unaffected; they simply will not provide access to the new rootUser objects. * User folder objects must be changed to support the rootUsers dictionary. The patch provides this support for the Zope UserFolder object. In practice, I believe that there is a relatively small (i.e. near-zero) number of publically-available user databases currently in existence which correctly support the Zope 2.2 security model, apart from those developed by DC themselves. Private developers of user databases need only implement the support if they would like the additional feature, and for the rest, I believe this patch should actually make it easier to implement 2.2 support for most such user databases, since they won't need to implement the creatable-by-super protocol or work through ownership issues.

o This would become Yet Another Undocumented Feature.

One of the big things that the dev area is going to do is to force us to assess the documentation impact of changes and ensure that the required documentation is produced and integrated with the appropriate offical or unofficial docs. I can see the expanded access file change potentially having an effect on at least two kinds of documentation (user/admin guides and developer materials regarding how to implement new kinds of user folders).

My assumption was that this feature would actually be easier for DC to document than explaining to someone why they have to log in as superuser, create a user folder, put a user in it, then log out by closing their browser, and then log back in again as that other user in order to start using their Zope installation. My intent was to make both your and my life easier, not more complex. I apologize for any such side effect. :(