Hi Ems Eril, What you are describing sounds like a somewhat involved project.
1) sounds interesting. in my estimation it should be possible, and even if it is a bit tricky I think the code changes should not be too extensive. I think the trick will be to get in there early (RepositoryManager, URI2RepositoryManager etc..) and switch the definition of the "website" (and maybe "dam") workspaces at a low level --> so that the rest of magnolia uses the new workspace whenever it accesses "website". You may have to wrap classes like the JcrSession. Interestingly, another user was asking a similar question recently on the list, but in the context of defining multiple website workspaces for use with different language versions of the content. 2) I *definitely* wouldn't try in this way. The Version API of JCR won't let you work with the content as if it were a "normal" tree of nodes. You'll have to watch what you version when very carefully. It is completely unclear how this would work. It will be a nightmare. 3) This approach can definitely work. A set of ACLs that gets adapted for each new project, perhaps a VirtualURIMapping or two to make the URLs work in a systematic way... I think this approach will require the least modification of existing code, but might require more custom code to perform the copies, create new ACLs, etc... This solution is least "intrusive" in terms of messing with the existing magnolia code. It should be possible for you to write a "projects" app that your admins can use to create and manage the project sites. *However* I think with any of these approaches you are glossing over the main difficulty: "Once they have completed their task the work is then merged back to the current stream." --> you're talking about merging content in the website tree... Currently there is no UI to perform a JCR-merge, and the semantics are complicated (consider when content gets moved, renamed and switched around in the hierarchy: you could create a situation where new content has parent and child nodes switched compared to old content --> how to cleanly merge this?) While I think it is theoretically possible, especially if you define the merge-semantics clearly and make certain assumptions, it is a very difficult task. Also, I would also consider adding a 4th approach to your list: 4) How about using additional authoring systems (or webapps), and using activation to move the content around? --> this provides a ready-made way to transport content between instances (although activation is not equal to merge). In this scenario each "project" could have its own author instance which is configured to publish back into the main instance. Something like that. Regards from Vienna, Richard > -----Ursprüngliche Nachricht----- > Von: [email protected] [mailto:user-list-owner@magnolia- > cms.com] Im Auftrag von ems eril (via Magnolia Forums) > Gesendet: Sonntag, 09. März 2014 03:18 > An: Magnolia User List > Betreff: [magnolia-user] Project Management capabilities within Magnolia > CMS > > I have a very unique requirement where I need to be able to create new > projects within web content management. To me a project is a clone of > existing set of websites ie pages, resources , dam etc. where individuals can > work on without effecting the current content. Ones they have completed > their task the work is then merged back to the current stream . The best > analogy would be how github works. The other spin to this is users are assign > to projects and only those user can see the content that have been created > or modified for that specific project . Im very new to Magnolia so at this > stage > Im trying understand the level of customization that would be required to > achieve this . If anyone has done anything similar I would love hear about it. > > Here are some ideas I was thinking . > > 1) Cloning workspaces and using JCR security to restrict access and finally > merging the changes of the workspace back to original workspaces . My > impression here is that it would require great deal of changes to the of core > magnolia . > > 2) Use of JCR versioning create hierarchal versions where the parent version > node represents project and apply permission at that level. > > 3) All content apps would have common node structure where multiple root > nodes represent project names . Using the security mechanism already in > place we can apply permission to those root nodes. I think this is similar to > how multisite works today but expanding this to other workspaces and > having a way to easily clone and merge the differences is missing. > > Thank you in advance > > -ems > > -- > Context is everything: http://forum.magnolia- > cms.com/forum/thread.html?threadId=a3680fae-94c6-4c0a-85e6- > 6d41e622779e > > > ---------------------------------------------------------------- > For list details, see http://www.magnolia-cms.com/community/mailing- > lists.html > Alternatively, use our forums: http://forum.magnolia-cms.com/ > To unsubscribe, E-mail to: <[email protected]> > ---------------------------------------------------------------- ---------------------------------------------------------------- For list details, see http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
