X-Git-Url: https://scm.cri.minesparis.psl.eu/git/GroupUserFolder.git/blobdiff_plain/e9d14b6b5cc9cd4775c60cb340b5c4c787536fc3..3e1ba4932c34812cf2f6f3569b0f0dbea97b7a0b:/Products/GroupUserFolder/design.txt?ds=inline diff --git a/Products/GroupUserFolder/design.txt b/Products/GroupUserFolder/design.txt new file mode 100644 index 0000000..871edc0 --- /dev/null +++ b/Products/GroupUserFolder/design.txt @@ -0,0 +1,34 @@ +Here are the main initial ideas behind GRUF : + + Before we started writing this component, we spent a lot of time on +the design (yes, using paper and pen ;)), thinking a lot on how to be +as generic as possible. As a conclusion of our design sessions, we came +up with the following requirements : + + - a group has to be seen by zope like an user. This way, we can +guarantee that the _whole_ standard security machinery of Zope will +continue to work like a charm, without even a hotfix. + + - a first consequence of this is that GRUF will work out of the box + with any Zope application, including Plone ;) + + - a second consequence is : groups just have to be stored in + a separate acl_users + + - GRUF must be able to handle _any_ existing acl_users component ; including LDAP + or sql one + + - GRUF has to be as transparent as possible to applications (read + "should act as a normal user folder") + + - Group nesting should be supported + + - Multiple sources for users should be supported (ex : source 1 is + SQL, source 2 is LDAP, source 3 is another LDAP). + + The API was designed, test cases were written, code was done, +documentation was written, first version went out and the first customers +were (very) happy. Yes, exactly in this order ;) + + +