rename zope.Public to public

[Steve Alexander]

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'.

[Jim Fulton (jim-zope)]

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 Alexander (stevea)]

Permission names should be dotted names, based on package names or URIs. However, zope.Public isn't really a permission like other permissions. It is a special token that means "this attribute need not be protected".

So, I think this special token should have a special name: "public".

[Steve Alexander (stevea)]

Feb 15 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

[Christian Theune (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 Alexander (stevea)]

'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.

[Christian Theune (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 digg into that and check if that's right

[Fred Drake (fdrake)]

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.

[Philipp von Weitershausen (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.

[Tres Seaver (tseaver)]

Now tracked on Github:

  https://github.com/zopefoundation/zope.security/issues/6