At 08:50 AM 7/13/00 +0100, Steve Alexander wrote:
"Phillip J. Eby" wrote:
Changes checked in. I should be releasing an alpha5 tomorrow.
That's great. Did you get my message about errors in triggered methods?
Yes, I did, but the solution requires some more thought. I had thought I had the "Transactional" machinery set up so that stuff was only called during transaction phases where it was safe to throw errors. So I'm going to have to go back and review that. However, I also think that errors in triggers should result in a rollback-and-abort, rather than silently failing, which could cause many other problems.
I realised that I only sent it to the zope-dev list, and not cc-ed to you.
Not necessary; my reading rate simply varies. :)
I had hoped to finish my work on proxy roles, ZClass plugins,
Does that increase the number of "Waaa!" comments in the code?
No, I hadn't even got that far yet. :)
and maybe even my local-roles stuff first and make it a "beta" release,
*If* you get time, can you put a note on the ZPatterns Wiki, or to the zope-dev mailing list briefly describing what proxy roles, and local roles mean in the context of ZPatterns? Thanks.
The proxy roles stuff is for Generic providers and triggers, so that when they execute your expressions they can have roles other than those of the current user, which is important for constructing secure applications. The local roles stuff is the ability to have a DataSkin get local role information from "local role providers", thus allowing rules-based local roles to exist/co-exist with the standard Zope persistently-managed local roles. One aspect that will be considered in the local roles work is adjusting the LoginUser class so that it can use more efficient ways of checking access to an object if it's a DataSkin. The built-in Zope approach has to look for *all* local roles that a user has, even when it only wants to know about one of them. In general I'd like to see Zope's local role API's tightened up in this fashion. Another tightening would be to use the user object rather than the user's ID or name when calling local-roles API's, since a rule-based approach may need to consult data on the user object.