Apply TAC authoring control to Documents content type?

[patdunlavey]

Once we get the TAC modules straightened out, I have a question about Robin S. uploading documents (to the Administrative and Forms documents sections).

Those pages add documents in a different way than the other other pages; one should use the Add a Document link at the bottom of the page for them to be automatically sorted into years (year updated, from what I can tell). Otherwise, if you click Edit and upload using "File Attachment", documents can be uploaded but won't be sorted; and may be uploaded to a different location...

When you click Add a Document, the resulting upload page doesn't have the "editorial section" highlighted, so I'm not sure Robin will be able to use it as planned.

There's always the possibility that Robin can upload using File Attachment and then I can Add a Document, later, but that seems inefficient.

Ideas? Thanks, Janet

[patdunlavey]

I think there is a misunderstanding about what TAC controls. On the content-authoring side, TAC-lite dictates which taxonomy terms a given author can apply to the content. It does not control permission to create content in the first place. That is controlled by core node permissions, and at the moment, there is no role enabled for authoring, other than "admin" and "super admin".

I would propose that we create at least one role for this purpose. If just one, then it should be called "content manager" (or use the "content editor" role, which seems to have no purpose at the moment) and it should be granted create/edit-own/delete-own permissions for a core set of content types (page, at least I'm not sure what other content types are meant to be used routinely,).

I don't know how widely the Documents content type is meant to be used, or really why it is a separate content type at all, or why there is another "Documents (m) content type" (I believe that its fields are identical to the page content type). But if we want to separate out privileges for documents content authoring, we could create a "documents manager" role, which has those permissions.

[ousaweb]

Ask Greg, but I think he was trying to use TAC-lite to limit content managers to certain pages for editing purposes.

If there's a better way to allow, say, Robert B to edit just the MtBO pages (and convention info) and none of the other pages, please let us know.

[patdunlavey]

TAC(& TAC-lite) does not control editing access (that's determined by core node permissions). It controls what taxonomy terms a given user can assign to a piece of content. That determines what section(s) the piece of content appears in. There is a module for controlling editing access by section called organic groups (a group member can have editing privileges over group content). But it's an access control module, which means that it may conflict with other access control modules (remember why we disabled project issues?). It's also a complete departure from how the site is currently designed, and would certainly be a very significant redesign project.

The simplest approach, which may not exactly be what you're looking for, is to give Rob B the following privileges (under some role to be determined): node permissions:

• create page content
• [create other content types?]
• edit own page content
• [edit own other content types?]
• [should he be able to delete his own content?]

We can use TAC-lite to constrain the Editorial Section that he can apply to any content that he has create/edit privileges on.

When "ownership" of content needs to switch, we can just change the content's author and configure the new author's settings (role and taxonomy access).

Downside is that only one non-admin person can have edit privileges over a given page at a time. It's not as elegant as organic groups, but very doable in the current configuration.

[bereginyas]

tac_lite is an access control module which allows view, update, and delete permissions to be set for individual users and/or roles, although not create permissions. Since it is an access control module, the users are not required to have "edit own page content" or similar permissions checked. See the permissions fieldset on this page: admin/user/access/tac_lite/scheme_2

We are using this module to good effect on QOC to limit a particular user to only be able to edit one specific page and that page alone. It should work quite well for the Robert B example above, provided the page(s) in question already exist. And it is not restricted to one person with edit privileges per page.

The only potential issue I know of is that a user with update permission for a page can change the taxonomy term tac_lite uses to determine permissions. If they change it to a term for which they don't have update permission through tac_lite, they can lock themselves out from being able to edit the page further. I haven't worried about a fix for this issue yet. Now that I think about it, they could also inadvertently allow the wrong people to edit the page (we only have the one vocab term on QOC, so it doesn't apply to our site yet). Ok, to fix this, offhand I might try adding an "#access" property to the taxonomy select list using a hook_form_alter, with a value determined by user role. Maybe there's a better way. There appears to be a "Visibility" checkbox in the admin page, but either it doesn't work or it's doing something other than what I am expecting.

Haven't even looked at taxonomy_access or og. Too many modules. :-)

[bereginyas]

Oh, I see now there is a second module included with tac_lite called tac_lite_create which works exactly as you describe - i.e. it does not add "create" permissions but just controls which taxonomy terms are available. That should really be renamed. tac_lite is a true access control module even if tac_lite_create is not. Messy. Worse, the documentation in the files themselves is out of date and does indeed say "Currently, this module works with view grants only (no update or delete grants)" which is actually incorrect, at least in 6.x-1.4.

[patdunlavey]

I finally understand how this is meant to work. I was stuck on the incorrect assumption that "content managers" need to be able to create content!

I implemented hook_form_alter to set #access = FALSE for the taxonomy, banner image and title form items - for page nodes, for people who are merely authenticated users and are not the author of the node. I'd like to figure out a way for these people to have a page that lists the content they can edit. I'll create a separate issue for that if an answer doesn't appear quickly.