WhitMtSprintWiki
a groupthink repository
Groupware Sprint Goals :
- - add/remove teamworkspaces
- - ldap integration (users, addresses)
- - calendaring (group calendars, user calendars)
- - todo items (group, user)
PLIPS effecting groupware
PLIP16:Local role improvements
PLIP28: AT Content types as default content types
"PLIP42: >CMFMember Integration
groupThink
In summation of a talk I recently gave, groupware in plone is evolving in many directions at once and though natural selection is a effective process over millions of years, most of our clients won't wait that long. Convergence is simply more efficient.
Groups, teams, assemblages, etc generally serve two types of purposes. The first is the abstract idea similar to the unix group: a ensemble of declaration of how an user behaves in the system. The second is as a representation of a real world set of human beings.
The first needs to be pervasive and auditable as it is a matter of security. The second is more malleable as the handmaiden the infinite and evil possibilities of business logic.
In this spirit, I advocate we take groupware along a similar route as CMFMember. CMFMember uses Archetype content objects as memberdata to allow for the rich extension of those objects. These content objects are store in portal_memberdata, a container, allowing for ease of management, just like....content: cut, paste, rename, workflow, etc.
Applying the same principle to portal_groups and portal_groupdata is a sensible next step.
Ideally, two tools would provide the interface whatever group implementation a developer chose, rendering unto Zope security and Plone(and Archetypes) content. If the hydra of current groupware implementation is any indication, a large amount of extensibility at the content->interface level is needed by developer on both side of the layer plone provide between zope and a shiny happy working site in a client's browser.
Some more groupthink: