Thanks for the feedback!
(answering a couple of points in this one mail)
Kapil Thangavelu wrote:
On Fri, 04 May 2007 14:54:59 -0400, Miles
<[EMAIL PROTECTED]> wrote:
I seem to be generating a sizable proportion of the traffic on this
list! Apologies in advance for another email...
My use case is as follows:
I have a zope website, a php forum and blog that make up my site,
each with their own user databases. Whenever users register through
the zope site (I have removed links so they cannot register
elsewhere), I want to create corresponding user accounts for them in
the database for the forum and the blog.
However, when a user is created, PAS runs through all the plugins
implementing the IUserAdder interface, but once a plugin indicates
that it created a user, it proceeds no further.
right, which makes sense to me, you don't really want it to create
multiple users, shadowing each other for login purposes. only one gets
to login. it sounds like you just want to have your custom useradder
plugin ordered higher than the default zodb user plugin.
Well, that is what I want to do - create multiple users in each of these
applications, but which all correspond to the same actual person/login.
This would mean the same account could be used to access all of them.
I guess the root of the issue is that there is no way that the
blog/forum apps can be coerced into using a single source of
usernames/passwords without substantial rewriting.
I had planned to create a 'blog useradder' plugin, and a 'forum
useradder' plugin, and use the existing 'zodb user manager', to deal
with creating users in each application, rather than a single
'blog+forum+zodb' useradder - in order to keep the code for each app
separated. Is a single, "large" plugin really the recommended approach
in this situation?
I can control which plugins fire by activating/deactivating the
IUserAdder interface and changing the order of the plugins from within
PAS, so the "only one plugin can create" restriction is already a bit
Wichert Akkerman wrote:
I think that a better approach would be to use events. I made a branch
a while ago which has an event which is fired when a new user is created
which solves your use case perfectly. That branch is still missing test
for the events though. Someday I need to write those and offer it up for
Is that the "z3-events" branch? I had a quick look. In my use-case,
anything subscribing to the IUserAdded event would also need to know the
original password for the user, in order to set it. I doubt that's a
I would like to change this so all IUserAdder plugins get a chance to
fire - does anyone have an opinion on it?
-1, we can not change semantics of existing interfaces.
I agree with this. Though the restriction is not documented anywhere: I
am happy to add some explanatory notes though.
Zope-PAS mailing list