Skip Navigation

[Resolved] Access and multi author editing

This support ticket is created 7 years, 7 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 -
- 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 -

Supporter timezone: Europe/London (GMT+01:00)

Author
Posts
#431850

Access and multi author editing

This is what I am trying to do-
I have a post type called obituary with a variety of fields about the deceased including photos and others' memorable anecdotes.
A member would create an obituary (not centrally via admin)
So far that author can go in and edit the obituary - add/ delete photos for example.

I have four related questions (I can split to separate support requests if need be)

1) Is it possible to set permissions so that another member or invited guest can also edit a specific Obituary? So Member B edits Member A's obituary but doesnt have site wide access to edit all obituaries or even other Obituaries Member A may have created

2) If so, can I set it it so they can upload/ edit/ delete their own photos BUT NOT photos from a different Member. Currently I have an image field with multiple instances allowed creating a 'Gallery'
So Memmber B can upload pics and delete them but cant edit Member A photos.

3) If it was the case that any member could edit, I can presumably set it to the post went to draft for review, BUT can I set it so Member A received notification and then approved the change and NOT admin.

4) If the above was true, then would the entire Obituary be in draft, or would a version pre-changes be viewable with changes live when approved.

If anyone could confirm if any of this is possible or how to approach it if not then I would appreciated it

#432405

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+01:00)

Please find answers for each of your questions below:

1. Access is designed to control content using the WordPress concepts of roles and capabilities, not by individual users. You can set general rules for a particular post type and then override these on individual posts using post groups (see: https://toolset.com/documentation/user-guides/limiting-read-access-specific-content/) but those settings would apply to all users with the same role (standard or custom).

You would either need to write some custom code to handle managing individual user access, or you can use conditional shortcodes to when displaying your output to test the user ids of those viewing the content to see whether they can view it or not (including links to CRED edit forms, for example). See https://toolset.com/documentation/user-guides/conditional-html-output-in-views/.

You have an issue generally of managing who can view and edit which content other than their own, and specifically, if you use conditional shortcodes, you will be managing the user ids manually in the page content, which quickly could become complex.

2. This rather depends on how you implement 1, and your general settings for whether members can edit their own content only or edit anyone's content.

3. Yes, that would work. https://toolset.com/documentation/user-guides/automated-email-notifications-with-cred/

4. The status of a post is the status of a post, so if the status is changed to draft then it would not be visible on the front end until its status had been returned to published. WordPress keeps a record of post revisions but doesn't have separate statuses for them.

You will probably need to do some more thinking. If you have follow up questions, please ask away.

#433999

Thanks for your help

This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.