> Is Facebook run by Magnolia? ;-) Now that would be an interesting project :D
> For comments this would work fine, but what about user accounts for > instance? If you allow your user to change his/her password and for > some reason you also need your editors to be able to work on the user > account (e.g. adding new groups)? Without really thinking about it for too long - first solution I'd try would be the classic divide&conquer ... change the structure to something like: user - username (the only really fixed and never changing prop of the user if necessary at all) - personalProps - password - real name - ... other user editable props - managedProps - groups - roles - ... the rest of the properties, i.e. anything i do not give to the user themselves to change directly, but is handled by editors See any obvious fault that I've missed with the above? The point I tried to stress is that the only change that could happen directly on the "user" node this way is when the node is deleted by admin. Otherwise the changes made by the users and by the editors are made in the independent sub-domains and will not collide ... unless, of course, the editor doesn't go and try to change the user password ... but that would be a thing I would likely prohibit anyway in such scenario. ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
