Zope 2.6 project updated
Hi all - I'm glad to see a thriving thread on 2.6 features :) To try to keep things manageable, I've created a project in the fishbowl at: http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/ ...to start getting the effort organized. In particular, I spent some time today going through the "call for contributors" thread and harvesting the various proposals: http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/ProposedFeatures I tried to capture who volunteered for what, but please look this over and let me know if I have you volunteered for something that you didn't mean to volunteer for :) You can also fix it yourself if you like (its a wiki). The next step will be to whittle down the proposals, so if anyone wants to add to the list (or volunteer themselves for something on it), now is the time. At this point there are as many items without volunteers as with, so please don't add any more proposals to the list unless you are also volunteering :) Brian Lloyd brian@zope.com Software Engineer 540.361.1716 Zope Corporation http://www.zope.com
Brian Lloyd wrote:
http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/ProposedFeatures
I tried to capture who volunteered for what, but please look this over and let me know if I have you volunteered for something that you didn't mean to volunteer for :) You can also fix it yourself if you like (its a wiki).
To stir things up some more: for my part, I don't like seeing "we need feature X" without the corresponding "I'll volunteer to write feature X." Items that dont get contributed probably are not going to survive. It's probably also worthwhile to consider "how do I make the least intrusive contribution" as well, such that we don't end up with highly-conflicting contributions. Products form fairly unintrusive contributions. Changes to ZServer cause headaches. :) I *really like* bugfixes or "feature fixes" though. -- Matt Kromer Zope Corporation http://www.zope.com/
Howdi. Well I saw the cookie crumbler wish has been added to the list already, and (as i tested it out this moment) don't see what exactly needs to be done than adding it by default to the root userfolder. Well, probably some facelifting to the default login, thats not urgent in any way but if wished i would do that. If I am wrong with the assumption above, tell me, and tell me what still needs to be done, then you can assign me to it (I am not a contributor currently, but sending in patches to the contributors is ok for me.) Greetings Christian -- Christian Theune - ct@gocept.com gocept gmbh & co.kg - schalaunische strasse 6 - 06366 koethen/anhalt tel.+49 3496 3099112 - fax.+49 3496 3099118 mob. - 0178 48 33 981 reduce(lambda x,y:x+y,[chr(ord(x)^42) for x in 'zS^BED\nX_FOY\x0b'])
Christian Theune wrote:
Well I saw the cookie crumbler wish has been added to the list already, and (as i tested it out this moment) don't see what exactly needs to be done than adding it by default to the root userfolder. Well, probably some facelifting to the default login, thats not urgent in any way but if wished i would do that.
Well, as far as "least-intrusive", CC loses some points by not being compatible with some of the user folders that do their own cookie auth, although that's arguably not CC's fault.
From: "Matt Behrens" <matt.behrens@kohler.com>
Christian Theune wrote:
Well I saw the cookie crumbler wish has been added to the list already, and (as i tested it out this moment) don't see what exactly needs to be done than adding it by default to the root userfolder. Well, probably some facelifting to the default login, thats not urgent in any way but if wished i would do that.
Well, as far as "least-intrusive", CC loses some points by not being compatible with some of the user folders that do their own cookie auth, although that's arguably not CC's fault.
Which makes me think of another point. I haven't used Zope 2.5.1 yet, but I understand from some of the traffic on the mailinglists that some have wanted to disable the session tracking/session management beause it interferes with the solutions they allready use for session tracking. And now there is a possible inclusion of another product (CC) that might conflict with other products' cookie functionality. Instead of locking up users with a particular implementation of a solution to a general problem, why not present an API for a) session management and b) cookie management, and then present default products that use these API's to provide solutions? This way it will not be hard to replace both session management and cookie management with other products. Any one else think that this might be a worthwhile idea? If so, I can offer time and effort and my limited knowledge of zope to make this possible. /dario
Howdi. On Tue, Mar 05, 2002 at 09:08:58PM +0100, Dario Lopez-Kästen wrote:
From: "Matt Behrens" <matt.behrens@kohler.com>
Well, as far as "least-intrusive", CC loses some points by not being compatible with some of the user folders that do their own cookie auth, although that's arguably not CC's fault.
Which makes me think of another point. I haven't used Zope 2.5.1 yet, but I understand from some of the traffic on the mailinglists that some have wanted to disable the session tracking/session management beause it interferes with the solutions they allready use for session tracking.
And now there is a possible inclusion of another product (CC) that might conflict with other products' cookie functionality.
Hmm. I didn't get an answer right now (well i don't find the question again too) if the cookie crumbler would interfere subfolders (distor through acquisition) or would only be active on a "sibling" userfolder, which he is "watching". In the case he would interfere the whole system if its installed at root level, i will agree to you completely that it shouldn't be that intrusive, in the other case i would say it's an acceptable option because the cookie crumbler would only be installed by default if the standard userfolder is instanciate (as i imagine this right now ...)
Instead of locking up users with a particular implementation of a solution to a general problem, why not present an API for a) session management and b) cookie management, and then present default products that use these API's to provide solutions? This way it will not be hard to replace both session management and cookie management with other products.
Any one else think that this might be a worthwhile idea? If so, I can offer time and effort and my limited knowledge of zope to make this possible.
cool in either case of the situation i think. Regards Christian -- Christian Theune - ct@gocept.com gocept gmbh & co.kg - schalaunische strasse 6 - 06366 koethen/anhalt tel.+49 3496 3099112 - fax.+49 3496 3099118 mob. - 0178 48 33 981 reduce(lambda x,y:x+y,[chr(ord(x)^42) for x in 'zS^BED\nX_FOY\x0b'])
Christian Theune wrote:
Hmm. I didn't get an answer right now (well i don't find the question again too) if the cookie crumbler would interfere subfolders (distor through acquisition) or would only be active on a "sibling" userfolder, which he is "watching".
I'm really not sure. I imagine it could be troublesome.
As far as I can tell from my experiences at work, the answer is somewhere in between. Yes it acts on all User Folders below the folder containing the CC, but it seems to get a little confused if the DTML scripts (Or at least some of them) are not in the same folder with each UF. Not fully tested as I say, but it is annoying. Didn't there used to be a UF with a checkbox "Use cookies" in it's properties. Can't this functionality be added to the basic UF API, to extend all UF's rather than adding an acquirable object that we might rather not acquire. Surely the nature of the logon method should be governed by some or all of the following: 1) The site designers wishes. 2) The browsers ability to do Basic Auth properly (Or at all). 3) The users preference (This might be undesirable in some cases). Adrian... -- The difficulty of tactical maneuvering consists in turning the devious into the direct, and misfortune into gain. - Sun Tzu ----- Original Message ----- From: "Matt Behrens" <matt.behrens@kohler.com> To: "Christian Theune" <ct@gocept.com> Cc: <zope-dev@zope.org> Sent: Tuesday, March 05, 2002 8:32 PM Subject: Re: [Zope-dev] Cookie Crumbler and similar products (Re: Zope 2.6 project updated)
Christian Theune wrote:
Hmm. I didn't get an answer right now (well i don't find the question again too) if the cookie crumbler would interfere subfolders (distor through acquisition) or would only be active on a "sibling" userfolder, which he is "watching".
I'm really not sure. I imagine it could be troublesome.
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Which makes me think of another point. I haven't used Zope 2.5.1 yet, but I understand from some of the traffic on the mailinglists that some have wanted to disable the session tracking/session management beause it interferes with the solutions they allready use for session tracking.
This is possible now. The sessioning solution is very general and everything is parameterized and can be disabled. AFAIK, the complaints I've seen so far have been attributable to folks just misunderstanding the management screens and thinking that the default sessioning configuration is immutable. - C
I like the idea of adding cookie auth to the API. The user product choices are convoluted and I think the community would benefit from adding standard capability to the core. Adding to that... my priority would be to extend acl_users folder to allow for built-in storage of additional user properties beyond username/password. Yes, there are user products that do this to a point, but an API that allows you to simply do it in ZODB would be ideal. Maybe someone more familiar could determine a "best of" integration that addresses acl_users folder extensibility and security to add this to Z2.6. -Trevor
-----Original Message----- From: zope-dev-admin@zope.org [mailto:zope-dev-admin@zope.org]On Behalf Of Dario Lopez-Kästen Sent: Tuesday, March 05, 2002 3:09 PM To: zope-dev@zope.org Subject: [Zope-dev] Cookie Crumbler and similar products (Re: Zope 2.6 project updated)
From: "Matt Behrens" <matt.behrens@kohler.com>
Christian Theune wrote:
Well I saw the cookie crumbler wish has been added to the list already, and (as i tested it out this moment) don't see what exactly needs to be done than adding it by default to the root userfolder. Well, probably some facelifting to the default login, thats not urgent in any way but if wished i would do that.
Well, as far as "least-intrusive", CC loses some points by not being compatible with some of the user folders that do their own cookie auth, although that's arguably not CC's fault.
Which makes me think of another point. I haven't used Zope 2.5.1 yet, but I understand from some of the traffic on the mailinglists that some have wanted to disable the session tracking/session management beause it interferes with the solutions they allready use for session tracking.
And now there is a possible inclusion of another product (CC) that might conflict with other products' cookie functionality.
Instead of locking up users with a particular implementation of a solution to a general problem, why not present an API for a) session management and b) cookie management, and then present default products that use these API's to provide solutions? This way it will not be hard to replace both session management and cookie management with other products.
Any one else think that this might be a worthwhile idea? If so, I can offer time and effort and my limited knowledge of zope to make this possible.
/dario
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Well. (This answer could also be posted a bit up the thread) I think we see that Cookie Crumbler may not be the solution to what i originally itended - the availability of cookie based authentication in the standard userfolder. Due to its problems, it seems as if it would be best, to extend the first userfolder again (currently a userfolder on the api has no idea about different authentication methods at all, or am i wrong?) but this would break the api - which changed in 2.5 afairk already - again, which i do not desire just for the sake of proper logout of management interface / cookie logins ... but i still believe it would be good to be there. Greetings Christian On Tue, Mar 05, 2002 at 03:31:50PM -0500, Trevor Toenjes wrote:
I like the idea of adding cookie auth to the API. The user product choices are convoluted and I think the community would benefit from adding standard capability to the core.
Adding to that... my priority would be to extend acl_users folder to allow for built-in storage of additional user properties beyond username/password. Yes, there are user products that do this to a point, but an API that allows you to simply do it in ZODB would be ideal.
Maybe someone more familiar could determine a "best of" integration that addresses acl_users folder extensibility and security to add this to Z2.6.
-Trevor
-- Christian Theune - ct@gocept.com gocept gmbh & co.kg - schalaunische strasse 6 - 06366 koethen/anhalt tel.+49 3496 3099112 - fax.+49 3496 3099118 mob. - 0178 48 33 981 reduce(lambda x,y:x+y,[chr(ord(x)^42) for x in 'zS^BED\nX_FOY\x0b'])
From: "Brian Lloyd" <brian@zope.com>
http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/ProposedFeatures
I tried to capture who volunteered for what, but please look this over and let me know if I have you volunteered for something that you didn't mean to volunteer for :) You can also fix it yourself if you like (its a wiki).
The next step will be to whittle down the proposals, so if anyone wants to add to the list (or volunteer themselves for something on it), now is the time. At this point there are as many items without volunteers as with, so please don't add any more proposals to the list unless you are also volunteering :)
Well, lets fix one of those things. :-) The "Enhanced virtual hosting" part of the "Enhanced virtual hosting / local roles blacklist" entry is really the same as the "Virtual Host Folder" further down, so that has a volunteer. And we at torped (That is me and Johan Carlsson) could do the "Local roles blacklist" part. We are not contributors yes, but Paul E suggested that we'd become that to fix some bugs that we want fixed in 2.5.1, and then we could do this also.
Well, lets fix one of those things. :-) The "Enhanced virtual hosting" part of the "Enhanced virtual hosting / local roles blacklist" entry is really the same as the "Virtual Host Folder" further down, so that has a volunteer. And we at torped (That is me and Johan Carlsson) could do the "Local roles blacklist" part.
We are not contributors yes, but Paul E suggested that we'd become that to fix some bugs that we want fixed in 2.5.1, and then we could do this also.
Great - I've update the proposed feature list. Brian Lloyd brian@zope.com Software Engineer 540.361.1716 Zope Corporation http://www.zope.com
I've also added the idea of a "Startup Script Directory" as a potential for Zope 2.5. This would be a filesystem directory that folks could place scripts that followed some sort of API which allowed them to make changes to a Zope site at startup - useful for en-masse data migration due to Product code changes. - C ----- Original Message ----- From: "Brian Lloyd" <brian@zope.com> To: "Lennart Regebro" <lennart@regebro.nu>; <zope-dev@zope.org> Sent: Tuesday, March 05, 2002 10:10 AM Subject: RE: [Zope-dev] Zope 2.6 project updated
Well, lets fix one of those things. :-) The "Enhanced virtual hosting" part of the "Enhanced virtual hosting / local roles blacklist" entry is really the same as the "Virtual Host Folder" further down, so that has a volunteer. And we at torped (That is me and Johan Carlsson) could do the "Local roles blacklist" part.
We are not contributors yes, but Paul E suggested that we'd become that to fix some bugs that we want fixed in 2.5.1, and then we could do this also.
Great - I've update the proposed feature list.
Brian Lloyd brian@zope.com Software Engineer 540.361.1716 Zope Corporation http://www.zope.com
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
If the VirtualHostFolder is included, that will mean OrderedFolder is also incorporated in 2.6. I think OrderedFolder should be added as its own item to the proposed features list for individual consideration. Then the question of "Resources" arises. That is Stephan's product, not mine, and it *may* have some issues in certain OS distributions (based on my experiences and another user's). So, it cannot be added itself without some work--further testing work if nothing else. Therefore, it needs a volunteer, and that volunteer should logically be Stephan. Stephan is busy with Zope3 at the moment. I have done some tweaking of OrderedFolder, and I am willing to help further, but he and I have different coding styles that made a previous collaboration a bit inefficient. OrderedFolder is Stephan's, and he should feel happy with how it is incorporated in 2.6. So, um, Stephan, any ideas? :-) I know you are busy, but are you interested in getting this in 2.6? I could help with testing as before, but I'd prefer to have you signed on as the primary resource. This would be a prerequisite for including VirtualHostFolder in any distribution. Thanks, all Gary
Gary Poster wrote:
So, um, Stephan, any ideas? :-) I know you are busy, but are you interested in getting this in 2.6? I could help with testing as before, but I'd prefer to have you signed on as the primary resource.
I don't know OrderedFolder very well but it'd be very useful in several of my projects, so I can volunteer a bit of time in helping to get it in Zope 2.6 as well. Regards, Martijn
I don't know OrderedFolder very well but it'd be very useful in several of my projects, so I can volunteer a bit of time in helping to get it in Zope 2.6 as well.
I'd rather see that you used your time to put Formulator into 2.6 :-P /Magnus
I don't know OrderedFolder very well but it'd be very useful in several of my projects, so I can volunteer a bit of time in helping to get it in Zope 2.6 as well.
Hi Martijn! If you do so, please check with me for the newest version of Ordered Folder. I have added a few features to OrderedFolder that I need for Kontentor. Some of them might be candidates for Zope 2.6, others maybe not. Currently, OrderedFolder has: - ordering support - filters (from the FolderFilter Product) - a maximum items support (not fully implemented yet) - properties to define a custom icon and MetaType - integrated "transparency" as an option (from Transparent Folders) - subobject type support Cheers Joachim
Hi!
That is Stephan's product, not mine, and it *may* have some issues in certain OS distributions (based on my experiences and another user's). So, it cannot be added itself without some work--further testing work if nothing else.
What kind of problems does OrderedFolder have? There is no OS-specific code AFAIK. It is possible that there are browser-specific issues in the frontend. But those would be easy to fix ... Joachim
From: "Joachim Werner" <joe@iuveno-net.de>
Hi!
What kind of problems does OrderedFolder have? There is no OS-specific code AFAIK. It is possible that there are browser-specific issues in the frontend. But those would be easy to fix ...
Hi :-) In certain circumstances, if you install OrderedFolder (0.5.1 is last I checked) without ZBabel, *all* of the buttons on the main OrderedFolder management page will have "None" for their label. I have not had time to narrow down what those "certain circumstances" are, but my iMeme FreeBSD Zope does exhibit the error, and my Windows box does not. When I have a second to breathe I'll try it on Linux with a completely clean Zope install. One other beta tester of VirtualHostFolder reported this error with OrderedFolder; I have not gathered information from him as to his OS etc. It may also occur only when you configure OrderedFolder in a certain way. My beta tester reported that if you installed ZBabel the problem went away. I have not tested this on my FreeBSD Zope. So--who knows. This needs some testing, if nothing else. I'll get around to it when I can, because Stephan said he was unable to replicate the error. Obviously, I didn't exactly give the most complete bug report ever. It may be an interaction problem or anything. It looks like I won't have much of a chance to look at this myself until next week. Thanks Gary
At 10:40 AM 3/6/2002 -0500, you wrote:
From: "Joachim Werner" <joe@iuveno-net.de>
Hi!
What kind of problems does OrderedFolder have? There is no OS-specific code AFAIK. It is possible that there are browser-specific issues in the frontend. But those would be easy to fix ...
Hi :-)
In certain circumstances, if you install OrderedFolder (0.5.1 is last I checked) without ZBabel, *all* of the buttons on the main OrderedFolder management page will have "None" for their label. I have not had time to narrow down what those "certain circumstances" are, but my iMeme FreeBSD Zope does exhibit the error, and my Windows box does not. When I have a second to breathe I'll try it on Linux with a completely clean Zope install. One other beta tester of VirtualHostFolder reported this error with OrderedFolder; I have not gathered information from him as to his OS etc. It may also occur only when you configure OrderedFolder in a certain way.
My beta tester reported that if you installed ZBabel the problem went away. I have not tested this on my FreeBSD Zope.
So--who knows. This needs some testing, if nothing else. I'll get around to it when I can, because Stephan said he was unable to replicate the error. Obviously, I didn't exactly give the most complete bug report ever. It may be an interaction problem or anything. It looks like I won't have much of a chance to look at this myself until next week.
If OF will make it in the core, the ZBabel stuff will be taken out of it in anyway, since no part of Zope has something like that in it. I am also tempted to say that only the ordering module should go in (maybe the limit as well), since other functionality seems too specific. Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management
From: "Stephan Richter" <srichter@cbu.edu>
If OF will make it in the core, the ZBabel stuff will be taken out of it in anyway, since no part of Zope has something like that in it. I am also tempted to say that only the ordering module should go in (maybe the limit as well), since other functionality seems too specific.
Hey Stephan. Makes sense. Maybe that would imply either a different name for the core product ("OrderedFolderLite" is a bad example of the idea, for instance) or some other similar accommodation for the fact that your full product will certainly still be needed/wanted in certain cases. I'd feel comfortable extracting the ordering stuff into a new "lite" product, if you wanted, but I have not looked at the limiting functionality. Do you or Joachim have time to do this yourselves, or to be a part of this somehow? Finally, is there any feeling for just adding the ordering functionality to the standard Zope folder/ObjectManager? Perhaps including a button and an API to hide/show the ordering tools? What do folks think? Gary
Stephan Richter wrote:
If OF will make it in the core, the ZBabel stuff will be taken out of it in anyway, since no part of Zope has something like that in it. I am also tempted to say that only the ordering module should go in (maybe the limit as well), since other functionality seems too specific.
Regards, Stephan
I am afraid I must second this opinion. We recently looked at OrderedFolder, thinking to subclass it to produce our Slideshow product. The idea was to make a lightweight web-based replacement for PowerPoint where you can define the order of the slides and can hide/show them individually. We found that it was actually easier to create our own "OrderedFolder" base class and subclass it rather than use OF because of the extra functionality we did not want. Of course, the extra functionality is probably really useful for some people. My vote would be to include _some_ additional functionality like defined orderings in the Zope3 core, and keep OF as a third party extension product which people can use or not. The Zope3 version of OF would then be simpler, as it would only have the remaining functionality (like "reverse" acquisition, setting a max limit on number of items, etc.) To summarize, I would like to see regular Zope Folders enhanced to optionally have some notion of type ( a la Brian's Zope 2.6 proposal "Object Type Assocation And Death To index_html" ) and basic ordering I am willing to help out. I would love to see this functionality in 2.6 and carry it forward to 3.0... my 2c, --Craeg
I am afraid I must second this opinion. We recently looked at OrderedFolder, thinking to subclass it to produce our Slideshow product. The idea was to make a lightweight web-based replacement for PowerPoint where you can define the order of the slides and can hide/show them individually.
Actually, there SmartWizard (of course built with OF), whcih can be used for Slideshows. I used it for all my talks last year.
We found that it was actually easier to create our own "OrderedFolder" base class and subclass it rather than use OF because of the extra functionality we did not want.
Really? You should just have used OrderedObjectManager as base class.
I am willing to help out. I would love to see this functionality in 2.6 and carry it forward to 3.0...
Ordering and the Limit code is already in the Zope 3 core. The advanced Folder version there is know as LoadedFolder. Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management
Stephan Richter wrote:
I am afraid I must second this opinion. We recently looked at OrderedFolder, thinking to subclass it to produce our Slideshow product. The idea was to make a lightweight web-based replacement for PowerPoint where you can define the order of the slides and can hide/show them individually.
Actually, there SmartWizard (of course built with OF), whcih can be used for Slideshows. I used it for all my talks last year.
For some reason we missed that one :-( Of course, we also wanted functionality like selectively hiding slides (that way you can have lots of slides in a standard slideshow and choose subsets for a particular presentation). Still, the Products _are_ quite similar. We might be able to collaborate, but I suspect the Zope-2 architectural limitations will make it pretty difficult. For example, we have three products that are related by inheritance, and even though _we_ wrote all of them, it was interesting how much extra work it was to make them extensible in this way. With the Zope-3 architecture it would be _much_ easier.
We found that it was actually easier to create our own "OrderedFolder" base class and subclass it rather than use OF because of the extra functionality we did not want.
Really? You should just have used OrderedObjectManager as base class.
Are you referring to the latest (0.4 IIRC) release? We did our work before that came out...
I am willing to help out. I would love to see this functionality in 2.6 and carry it forward to 3.0...
Ordering and the Limit code is already in the Zope 3 core. The advanced Folder version there is know as LoadedFolder.
Excellent! I think Zope-3 anticipation is building to a fever pitch.... ;-) --Craeg
On Mon, Mar 04, 2002 at 05:40:39PM -0500, Brian Lloyd wrote:
Hi all -
I tried to capture who volunteered for what, but please look this over and let me know if I have you volunteered for something that you didn't mean to volunteer for :) You can also fix it yourself if you like (its a wiki).
Is it too late for new proposals? A lot of people seem to want the dtml-set tag to go into the main distribution. I know that ZPT is the way to go, but DTML will stick around for a while, and dtml-set makes coding DTML more bearable. If you don't know the dtml-set tag, have a look at http://www.zope.org/Members/ivo/SetTag Cheers, Ivo -- Drs. I.R. van der Wijk -=- Brouwersgracht 132 Amaze Internet Services V.O.F. 1013 HA Amsterdam, NL -=- Tel: +31-20-4688336 Linux/Web/Zope/SQL/MMBase Fax: +31-20-4688337 Network Solutions Web: http://www.amaze.nl/ Consultancy Email: ivo@amaze.nl -=-
While we are asking, I have two things that I would consider valuable additions to Zope 2.6: 1. UserSniffer. Currently an External Method, but has functionality that should be available OOTB to assist making those (horrors!) browser-dependent hacks. It has other uses, too, like explaining to clients that their browser is five years old and needs the free upgrade that is available. 2. Support for HTTP_X_FORWARDED_FOR. Many (most?) of us run zope behind Apache ProxyPass or Squid, and the Zope logs therefore save the ip address of the proxying machine rather than any semblance of where the client browser is. I realize that other proxies do not always follow the rules, etc., etc., but I think that using HTTP_X_FORWARDED_FOR if not null would be better than a log full of 192.168.1.1. Apologies if these have already been discussed under another heading. -- Jim Washington
Hi. 1) If the projects for which I have volunteered are accepted as a goal for Zope 2.6 then I have some work cut out for me, and I'd like to try to schedule the necessary time intelligently and early. Any ideas on when the "grocery list" will be evaluated? 2) If we had a brief Zope 2.6 style guide, similar to the Zope 3 stuff, that would be cool. In particular I'd like to be able to see "state of the art" 2.x ZC unit test approaches. Just point to a canonical example in Zope 2.5 or CMF, maybe? Is ZUnit (https://sourceforge.net/projects/zunit/) becoming canonical? A lighter-weight solution? Thanks Gary
Hi all -
1) If the projects for which I have volunteered are accepted as a goal for Zope 2.6 then I have some work cut out for me, and I'd like to try to schedule the necessary time intelligently and early. Any ideas on when the "grocery list" will be evaluated?
I think that this needs to happen Real Soon. I propose that this friday (the 15th) is the deadline for adding/volunteering for the 2.6 plan. After Friday, we need to cull the list to something managable (there is quite a lot there now). I further propose that any item on the list that does not have a sponsor (someone who has explicitly signed up to see the feature through, incl. associated tests, documentation, API help etc.) by Friday gets dropped from the plan. The working timeline for Zope 2.6 is to have an alpha out in about 6 weeks (beginning of May). Things whose sponsors don't think they can make that timeline should probably come off of the 2.6 plan (though they certainly can continue the projects, they would just go into a later release). So let's see what the list looks like after Friday when we know what is unchampioned or will not fit in the timeframe. Early next week, we should plan to debate the remaining items and finalize the list. It would be great if those who have volunteered to lead 2.6 projects could contact me with a rough est. of how long you think it will take and what collateral tasks there will be (any updating of existing documentation, new docs / API help and unit tests). I'll volunteer to update the plan in a little more detail.
2) If we had a brief Zope 2.6 style guide, similar to the Zope 3 stuff, that would be cool. In particular I'd like to be able to see "state of the art" 2.x ZC unit test approaches. Just point to a canonical example in Zope 2.5 or CMF, maybe?
I think any of the /tests directories in the Zope core are decent examples. Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
I think that this needs to happen Real Soon. I propose that this friday (the 15th) is the deadline for adding/volunteering for the 2.6 plan.
Okay, I'm a bit late but I'd like to integrate what's currently in NuxUserGroups, a bit updated maybe. http://www.zope.org/Members/nuxeo/Products/NuxUserGroups There will be a merge conflit with Lennart's Local roles blacklists, it it's chosen for 2.6, but I'm familiar enough with both code sets to manage the merge. I'm adding this proposal to the wiki. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 10 http://nuxeo.com mailto:fg@nuxeo.com
Florent Guillaume wrote:
Okay, I'm a bit late but I'd like to integrate what's currently in NuxUserGroups, a bit updated maybe.
http://www.zope.org/Members/nuxeo/Products/NuxUserGroups
There will be a merge conflit with Lennart's Local roles blacklists, it it's chosen for 2.6, but I'm familiar enough with both code sets to manage the merge.
I'm adding this proposal to the wiki.
I do recall that we looked at NUG as XUFers at at one point, and akm said it looked like it'd be compatible, although we still needed UI for groups in XUF. Nobody has done this, incidentally. :-) I'm not convinced that it'll go so well with other user folders. My gut feeling is that while groups are a very, very good thing (we NEED them here), and I'd love to see them in Zope 2, I think the issue of compatibility with all the other user folders out there is going to be a huge sore spot. So, -1, unless you can prove to me that every user folder on zope.org that hasn't already been obsoleted due to Zope changes will also work with NUG integrated (and the unfortunate fact that everyone probably has to change UI probably makes that a non-issue.) This coming from a guy who really wants groups. :-/
The design will carefull take into account backward compatibility. You can still have a user folder that doesn't know about groups, in which case the users won't have groups associated to them. No problem. The design goes like that: the local role machinery is patched to take into account groups *if the user folder can deal with them*. Otherwise nothing at all is changed. The folders can be converted one by one when needed. Someone already sent me a patch for LDAPUserFolder. XUF can follow whenever they're ready, I'll be ready to help. If you look at current NUF, the main changes would be added tests before any use of the user.getGroups() method [which I'll rename to user.getUserGroups() because getGroups is already taken by LDAPUserFolder]. In any case I'll put the code in a CVS branch sometime this week or the next, and we can discuss the impact. Code speaks :-) Florent Matt Behrens <matt.behrens@kohler.com> wrote:
Florent Guillaume wrote:
Okay, I'm a bit late but I'd like to integrate what's currently in NuxUserGroups, a bit updated maybe.
http://www.zope.org/Members/nuxeo/Products/NuxUserGroups
There will be a merge conflit with Lennart's Local roles blacklists, it it's chosen for 2.6, but I'm familiar enough with both code sets to manage the merge.
I'm adding this proposal to the wiki.
I do recall that we looked at NUG as XUFers at at one point, and akm said it looked like it'd be compatible, although we still needed UI for groups in XUF. Nobody has done this, incidentally. :-) I'm not convinced that it'll go so well with other user folders.
My gut feeling is that while groups are a very, very good thing (we NEED them here), and I'd love to see them in Zope 2, I think the issue of compatibility with all the other user folders out there is going to be a huge sore spot.
So, -1, unless you can prove to me that every user folder on zope.org that hasn't already been obsoleted due to Zope changes will also work with NUG integrated (and the unfortunate fact that everyone probably has to change UI probably makes that a non-issue.) This coming from a guy who really wants groups. :-/ -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 10 http://nuxeo.com mailto:fg@nuxeo.com
I also want groups! But I want a different kind of groups, that I call "workgroups" just to distinguish them from all other types of "groups". :-) I don't know if it's possible implement this compatibly in 2.x, and I can't judge if there is any problems in implementing one type of groups in 2.x and then switching in 3.x. And of course, I'm worried that implementation of groups in 2.6 will lessen the possibilities of getting workgroups into 3.x. :-) A workgroup is a set of users, just like I understand that NuxUserGroups are. But you set up a workgroup just like you would set up the local roles for a folder, ie, you do not only assign users to the workgroup, *you also assign roles to them within this workgroup*. When setting up a workgroup you don't get access to anything but the workgroup itself. But, you can then add any number of workgroups to a Zope folder, and the users in that workgroup would get the roles they were assigned in the workgroup to that folder. That way you still get the grouping and indirection that you get from otehr grousp, but you also get a greater automatic granularity in that grouping. So, in technical terms a workgroup is macro of role definitions. When you add a user to the workgroup and give him a Reviewer role, he will get the Reviewer role at all the folders where the workgroup is added to the workgroup list. The workgroup "Boss" will get the "Boss" role in all the places where this workgroup is added. With normal grouping, you typically have one group per department, and give that department access to a couple of parts of the database. Then you have a group of the Bosses that have more access. But usually this means that all the Bosses have Boss access everywhere, which is not necessarily what you want. So, even if it is very tempting to let Florent implement the local roles blacklist instead of doing it ourselves :-), I'd rather wait for workgroups than standard groups. In any case Johan and me would be very happy to help Florent and the others at Nuxeo implement it groups and blacklists. Best Regards Lennart Regebro Torped Strategi och Kommunikation AB
On Tue, Mar 19, 2002 at 04:11:05PM +0100, Lennart Regebro wrote:
I also want groups! But I want a different kind of groups, that I call "workgroups" just to distinguish them from all other types of "groups". :-) I don't know if it's possible implement this compatibly in 2.x, and I can't judge if there is any problems in implementing one type of groups in 2.x and then switching in 3.x. And of course, I'm worried that implementation of groups in 2.6 will lessen the possibilities of getting workgroups into 3.x. :-)
A workgroup is a set of users, just like I understand that NuxUserGroups are. But you set up a workgroup just like you would set up the local roles for a folder, ie, you do not only assign users to the workgroup, *you also assign roles to them within this workgroup*.
When setting up a workgroup you don't get access to anything but the workgroup itself. But, you can then add any number of workgroups to a Zope folder, and the users in that workgroup would get the roles they were assigned in the workgroup to that folder.
That way you still get the grouping and indirection that you get from otehr grousp, but you also get a greater automatic granularity in that grouping.
So, in technical terms a workgroup is macro of role definitions. When you add a user to the workgroup and give him a Reviewer role, he will get the Reviewer role at all the folders where the workgroup is added to the workgroup list. The workgroup "Boss" will get the "Boss" role in all the places where this workgroup is added.
With normal grouping, you typically have one group per department, and give that department access to a couple of parts of the database. Then you have a group of the Bosses that have more access. But usually this means that all the Bosses have Boss access everywhere, which is not necessarily what you want.
So, even if it is very tempting to let Florent implement the local roles blacklist instead of doing it ourselves :-), I'd rather wait for workgroups than standard groups. In any case Johan and me would be very happy to help Florent and the others at Nuxeo implement it groups and blacklists.
I needed a generalization of this scheme (and so ended up writing my own User Folder). We manufacture parts which are controlled by second parties, but bought primarily by third parties. I will call these parties Manufacturer, Brand Owners, and Contractors. I now have two kinds of administrators, and two kinds of users. There are unrestricted administrators and users. Since this really is enforced only at the user folder level (normal zope machinery is used elsewhere), a quick description is that an unrestricted administrator may create, modify or destroy any user or Brand Owner Name, and may associate any list of Brand owner names with any user. Any unrestricted user has a flag designating him as such and it is expected that application code check the flag and permit access to the contents held for Brand Owners. Restricted Administrators may create new users, modify users, or delete (some) users. However, any user they create may have only a subset of their brand owner name list (and their normal zope permissions). They may remove any of their brand names from a user that has one or more of the brand names under their control. They may delete users that have brand names only under their control. They may also create other administrators, subject to the subset restictions. Restricted Users have a brand list associated with them. Application logic can use this brand list to filter content. The restricted administrator is a big deal to us. If this takes off, we will not be able to properly control the set of Restricted Users (at Brand Owners and Contractors). Failure to do so could lead to legal exposure, so by creating Restricted Administrators who are Brand Owners, the contrl (and thus most of the legal exposure) can be shifted back to the Brand Owner. Jim Penny
Best Regards
Lennart Regebro Torped Strategi och Kommunikation AB
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Jim Penny <jpenny@universal-fasteners.com> wrote: [...]
I needed a generalization of this scheme (and so ended up writing my own User Folder).
We manufacture parts which are controlled by second parties, but bought primarily by third parties. I will call these parties Manufacturer, Brand Owners, and Contractors.
I now have two kinds of administrators, and two kinds of users. There are unrestricted administrators and users. Since this really is enforced only at the user folder level (normal zope machinery is used elsewhere), a quick description is that an unrestricted administrator may create, modify or destroy any user or Brand Owner Name, and may associate any list of Brand owner names with any user. Any unrestricted user has a flag designating him as such and it is expected that application code check the flag and permit access to the contents held for Brand Owners.
Restricted Administrators may create new users, modify users, or delete (some) users. However, any user they create may have only a subset of their brand owner name list (and their normal zope permissions). They may remove any of their brand names from a user that has one or more of the brand names under their control. They may delete users that have brand names only under their control. They may also create other administrators, subject to the subset restictions.
Restricted Users have a brand list associated with them. Application logic can use this brand list to filter content.
The restricted administrator is a big deal to us. If this takes off, we will not be able to properly control the set of Restricted Users (at Brand Owners and Contractors). Failure to do so could lead to legal exposure, so by creating Restricted Administrators who are Brand Owners, the contrl (and thus most of the legal exposure) can be shifted back to the Brand Owner.
This screams of ACLs for user management... I'm having the need too, in the context of CMF. I ended up writing an additional service (portal_directory) that has a complex set of ACLs to mediate access to the user folder. Some code will be released soon. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 10 http://nuxeo.com mailto:fg@nuxeo.com
From: "Jim Penny" <jpenny@universal-fasteners.com>
I now have two kinds of administrators, and two kinds of users.
An interesting case. If I understand it correctly, with our workgroups scheme,the restricted administrators would have administration rights on a workgroup. They would then be able to create users and add them to the workgroup they manage, but they wouldn't be able to give the users any priviligies outside the workgroup, and hence the new users priviligies would be limited to whatever priviligies they can get through the workgroup.
On Wed, Mar 20, 2002 at 07:01:13PM +0100, Lennart Regebro wrote:
From: "Jim Penny" <jpenny@universal-fasteners.com>
I now have two kinds of administrators, and two kinds of users.
An interesting case. If I understand it correctly, with our workgroups scheme,the restricted administrators would have administration rights on a workgroup. They would then be able to create users and add them to the workgroup they manage, but they wouldn't be able to give the users any priviligies outside the workgroup, and hence the new users priviligies would be limited to whatever priviligies they can get through the workgroup.
Right, although they may have adminstration priveleges on a set of workgroups. To give a motivation, consider a large company that has parallel design groups. The groups are intentionally kept in the dark about the other groups' work. Some companies do this to get a variety of choices to base the final decision on. Just to label them, call them Green, Blue, and Red teams. In this case, I might delegate an administrator who has authority over all of these teams, i.e, the administrator can (partially) control users or other administrators who have a subset of (Green, Red, and Blue) in their group list. The administrator, being a busy fellow himself, might create a Red administrator, who can (partially) control users or other adminstrators that have Red in their group list. Now, I am not really deep into modifying Zope core code at this point. The list of acceptable groups is available for any given user. The application programmer handles authorization and presentation. We have to have this for both reasons of scale and delegation of authority. Some, even many, of the design teams themselves use sub-contractors. We have no way of knowing the contractor's day-to-day relationships with the groups, and prefer not to know. Also, we are in a somewhat incestuous industry, and people move from company to company. While they obviously have what is in their head at the time of the move, we do not wish to give them knowledge of future plans. There are interesting policy decisions to make. Should an administrator be allowed to grant workgroup access to a pre-existing user? Can an administrator change a pre-existing user into an administrator? What does delete mean if the use has workgroups that the administrator does not control? Can the administrator see what workgroups the user has? Jim
I'm trying to wrap my mind around what you call workgroups. By the way, have you reviewed the use cases for workgroups that I put in http://www.zope.org/Members/nuxeo/Products/NuxUserGroups/README.txt ? Lennart Regebro <lennart@torped.se> wrote: [...]
With normal grouping, you typically have one group per department, and give that department access to a couple of parts of the database. Then you have a group of the Bosses that have more access. But usually this means that all the Bosses have Boss access everywhere, which is not necessarily what you want.
No no no ! With NUG the Roles added to a group are still added at the local role level, which means that the 'bosses' group only has a Boss role where you want it. Besides in the current NUG I don't yet have a way to assign a global Role to a group (this can be added later anyway, the current model is all that we needed, and the implementation is flexible enough to permit it later). I really think that my model can be used for what you do.
So, even if it is very tempting to let Florent implement the local roles blacklist instead of doing it ourselves :-), I'd rather wait for workgroups than standard groups. In any case Johan and me would be very happy to help Florent and the others at Nuxeo implement it groups and blacklists.
Thanks. But I insist that "my" groups are nearly the same as "your" workgroups. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 10 http://nuxeo.com mailto:fg@nuxeo.com
From: "Florent Guillaume" <fg@nuxeo.com>
No no no ! With NUG the Roles added to a group are still added at the local role level, which means that the 'bosses' group only has a Boss role where you want it.
Yes, of course. But what I was aiming at is that all the Bosses have Boss right at all the places where the Boss group have rights. There is no way to differentiate within one group.
I really think that my model can be used for what you do.
Sure it can. What you have to do is that for each role that you want within a workgroup you will have to create one group. So if you have ten departments, and you have five roles within these departments (f ex authors, reviewers, HR, CR and Bosses), you just create 50 different groups, one group for each department and role, and assign the permission for each of these fifty roles at the correct locations in the hierarchy. In a nightmare scenario, each department should have exclusive access to say 2 areas, and access to one shared area. This means that you need to do 50*3 = 150 group to roles mappings. So yes, you can. It's just more work. Just as if this was done without any groups at all, you would have to add each user to the local roles to each place. Say 15 users in each department times ten departments is 150 users times 3 locations gives you 450 separate assignments. No fun. With workgroups you create ten workgroups. Within each workgrup you assign users to their respective roles. You then add the workgroups to the correct places in the hierarchy. It also opens for the possibility to assign workgroup managers that can create users and add them to their groups without having any other manager rights (although this could be added later to make it easier to implement).
By the way, have you reviewed the use cases for workgroups that I put in http://www.zope.org/Members/nuxeo/Products/NuxUserGroups/README.txt ?
Now I have. :-)
Lennart Regebro <lennart@torped.se> wrote:
With workgroups you create ten workgroups. Within each workgrup you assign users to their respective roles. You then add the workgroups to the correct places in the hierarchy. It also opens for the possibility to assign workgroup managers that can create users and add them to their groups without having any other manager rights (although this could be added later to make it easier to implement).
Okay now I understand. It's indeed another form of indirect management of local roles. In getRolesInContext you'd have to have examine __ac_local_workgroups__, containing the list of workgroup ids, and to know what user->role mapping a workgroup has you'd have to consult the place where the workgroup definitions are stored, probably the acl_user of the user we're currently looking at. Then it's simply :-) a matter of user interface. There's also the question of what permissions are needed to modify a workgroup of course. Does this match what you want ? Looks quite feasible to me, and I think it can be done pretty independantly of the user groups I propose. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 10 http://nuxeo.com mailto:fg@nuxeo.com
From: "Florent Guillaume" <fg@nuxeo.com>
Then it's simply :-) a matter of user interface. There's also the question of what permissions are needed to modify a workgroup of course.
Does this match what you want ?
Yeah, I think so.
Looks quite feasible to me, and I think it can be done pretty independantly of the user groups I propose.
Hmm, yeah, thats true, it would be possible to have both, even though they aim to solve the same problem. Wouldn't it be a bit confusing to have both? Too may different ways of giving a person a role.
Lennart Regebro <lennart@torped.se> wrote:
Hmm, yeah, thats true, it would be possible to have both, even though they aim to solve the same problem. Wouldn't it be a bit confusing to have both? Too may different ways of giving a person a role.
The use cases are somewhat different though. I don't see a problem having them both. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 10 http://nuxeo.com mailto:fg@nuxeo.com
participants (20)
-
Adrian Hungate -
Brian Lloyd -
Chris McDonough -
Christian Theune -
Craeg K. Strong -
Dario Lopez-Kästen -
Florent Guillaume -
Gary Poster -
Ivo van der Wijk -
Jim Penny -
Jim Washington -
Joachim Werner -
Lennart Regebro -
Lennart Regebro -
Magnus Heino -
Martijn Faassen -
Matt Behrens -
Matthew T. Kromer -
Stephan Richter -
Trevor Toenjes