RunDMC
RunDMC copied to clipboard
marklogic-community
Authoring content requires admin access
I tried setting someone up with the dmc-user role, but he got errors. Set up the app so that having a sub-admin role is sufficient.
This is going to likely require setting up some permissions on the documents, which I don't think they have.
Yeah, I tried xdmp:document-get-permissions() on a doc and got nothing. Not sure when I'll get to this, but wanted to capture it.
I do this on the docs side internally by having a user that loads the content have default permissions that puts an update permission for the privileged role and a read permission for the user role. Then it requires a user with that privileged role to update the content, but the a lesser role can read the content. For the staging content, you would probably need another layer of permissions so normal users could not see that content until it was approved.
mariannemyers has offered to work on this, so I'd like to add some more detail. I want to have roles for dmc-author and dmc-admin, such that either person can go to the DMC admin tool, see the list of content, create new content, and edit content. Only a dmc-admin (who inherits the dmc-author role) can change a piece of content from "Draft" to "Published".
At least for now, I don't foresee this affecting how content is viewed by users of RunDMC, just the admin tool. At some point, the dmc-admin will be able to push content to the production database without having to ssh onto the server and run a script.
How should the documents permissions be handled? I submitted PR #362 that adds new roles - dmc-author and dmc-admin and uses these roles to control access to the publish/unpublish function. Currently a dmc-author user will not see any documents that were previously inserted/updated by the admin since no document permissions exist (yet).
https://github.com/marklogic/RunDMC/blob/docapp/src/model/data-access.xqy#L158 does a little prep work for this, commit 3db3698d6d1553f5477c53012a960f88d3e3ff41, by wrapping xdmp:document-insert calls in a library function for docs setup. However there are still a couple dozen calls elsewhere.
Should I proceed further with adding document permissions, using commit 3db3698 as a guide?
@mariannemyers, sorry for the delayed response. Yes, please proceed. That commit looks like a good approach. It relies on xdmp:default-permissions(), which should work fine.
Should only documents created/updated via the Admin UI be wrapped in a similar ml:document-insert? My thought is to add a new module to src/admin/controller/modules/doucment-insert.xqy and edit appropriate calls to xdmp:document-insert under src/admin/controller to something similar to the ml:document-insert in commit 3db3698.
I do not believe all xdmp:document-insert calls throughout the app should be changed, only the ones specifically in the src/admin/controller.
Yes, I agree with that. Please include the Media document insert.
On Fri, Jan 23, 2015 at 6:52 PM, Marianne Myers [email protected] wrote:
Should only documents created/updated via the Admin UI be wrapped in a similar ml:document-insert? My thought is to add a new module to src/admin/controller/modules/doucment-insert.xqy and edit appropriate calls to xdmp:document-insert under src/admin/controller to something similar to the ml:document-insert in commit 3db3698 https://github.com/marklogic/RunDMC/commit/3db3698d6d1553f5477c53012a960f88d3e3ff41.
I do not believe all xdmp:document-insert calls throughout the app should be changed, only the ones specifically in the src/admin/controller.
— Reply to this email directly or view it on GitHub https://github.com/marklogic/RunDMC/issues/338#issuecomment-71286852.
http://blog.davidcassel.net http://www.linkedin.com/in/davidcassel