rename zope.Public to public

[tseaver]

In https://bugs.launchpad.net/zope.security/+bug/97993, Steve Alexander ([email protected]) reported:

The zope.Public permission is nothing to do with Zope 3 really. It is more to do with the security system. It should be renamed to simply public.

@jimfulton followed up:

If it was specific to the app server, it might be zope.app.public. If we were going to change it, we should change it to zope.security.public.

Permission ids should be ids, and thus either dotted names, based on package names or URIs. In the interest of brevity, I prefer zope.Public.

Steve replied:

Feb 15 2005, 13:16:24, #zope3-dev

 <SteveA> zope.Public isn't really a permission.
 <SteveA> it is a token that means "don't invoke most of the security system"
 <SteveA> you can rename any other permission in your system.
 <SteveA> it should be "public"
 <srichter> it should be easy to change
 <SteveA> the "zope." in it is rather different than in "zope.ManageContent" for example.
 <SteveA> I have had to add to my system documentation an explanation for why we need a zope.Public permission when our other 6 permissions are launchpad.Whatever
 <SteveA> because it makes it hard to understand
 <SteveA> i also have to very carefully explain why it is special
 <SteveA> it *is* special, so I think it should have a special name.
 <SteveA> it could be aliased as zope.Public, as a deprecation measure. But, I'd like it to be just "public".
 <J1m> I'm OK w that

@ctheune:

I looked into this and found out that there is a minor problem with 'public': permissions have to be dotted names and dotted names have to have at least one dot in their name.

Suggestions?

Steve:

public should be a special token. It isn't even a permission inside the zope security machinery, as it is always optimized to the special CheckerPublic singleton.

Other permissions should always contain a dot.

@ctheune:

Hmm. So that might require a bit more work then the current registration of zope.Public because we have to refer to public in a lot of places where it will be checked for as a dotted name.

Permission definition likely will not be the only place, but also those places referring to it ... I'll dig into that and check if that's right.

@freddrake:

Doesn't this suggest that the problem can be substantially addressed by creating a "permission" field type that can be either "public" or a dotted name? I'd be inclined to do that even if it were just a dotted name.

@philikon:

I'm +1 on SteveA's suggestion to make public a special token for permission fields and deprecate zope.Public. This will also simplify things on the Five end, btw.

Fred: There already is a Permission ZCML field (zope.app.security.fields.Permission) that would simply have to be adapted to deal with public and issue deprecation warnings for zope.Public This would be trivial.