I've tried uploading the patch provided in errata instead but this hasn't changed anything. If I set the post status to publish, the link shows which I believe rules out any other issues affecting the display.
Sorry yes, you're right; it's a bit confusing when really old errata links appear above support threads and I just saw '5' in the version number and thought there'd been another release without noticing the 8 was missing!
yes, I do have an instance where the link doesn't show if the post is draft status. I can't find any other similar recent threads but I might be the first to notice (unless there's something else going on for me). Are you able to easily see if you can replicate?
After a bit more digging and testing with a new meagre site, I found the problem was to do with incorrect permissions within Access. These were imported using the Toolset export/import feature. The User's custom role had edit_others_posts enabled in the previous site so it looks like it dropped out during the import. This is something I've noticed before but haven't looked into this closely enough to be 100% sure. I don't currently have time to do this but it's on my list!
I've also noticed this: if a User's custom role has permission in Access to edit another User's posts using CRED, this only works if the post is published. For the custom role to be able to edit another's posts using CRED where the post status is draft, that custom role also needs to have edit_others_posts capability enabled. Is this expected/intended?
I'm using a new-ish test site with all current plugin versions (after yesterday's updates).
I created a custom role (which I copied from author, that cannot normally edit others' posts).
I brought a post type under Access control (tested both Posts and CPTs), and granted the alt-author role "Edit any" ability.
I then logged-in with a user with this role in another browser, and I was able to edit posts authored by a different user that had draft status.
On the Access settings page I had wondered whether it would be necessary to also grant the "Preview any" ability to edit drafts, but that wasn't necessary.
From my perspective, everything appeared to work as expected.
Are 'edit any' and 'preview any' new to the latest Views & Forms updates (cos I can't find them in the previous versions)? If so, are these role settings or form settings?
I use Access to manage Forms and Custom Roles only. So in my scenario, my custom role (based on Contributor) has 'Edit Others' set for the Form but the user with that role can only edit the draft post using the Form if I additionally check edit_others_posts (via Custom Roles > Change Permissions > Other Capabilities) for the custom role.
It also seems to be working with an alternative Contributor role, as long as I set the permissions for the post type and the form, without the need to add any custom permissions, not sure why you are finding different...
Just to clarify my setup: in Access Control under the Post Types tab, all standard & custom posts are set to 'Not managed by Access'. In the Toolset Forms tab, both post and user forms are managed by Access. Under the Custom Roles tab, I have created some custom roles. One of these roles has the 'Edit Others Custom Post Form XYZ' checked for a few forms. None of the Users have access to wp-admin, everything is created/amended on the frontend.
What happens if you mirror my setup (i.e. stop managing posts with Access)?
I haven't upgraded yet - I wanted to resolve/bring to a conclusion this matter first. Having said that, I have a basic, unimportant site where I've now upgraded, implemented some basic stuff to mirror my setup on the dev site so you can take a look (the issue for me is no different with latest versions). Would you like to provide private fields for log in to the site? I'll set up an admin role for you and give you the credentials for the test user too.
But you must manage posts with Access if you want to grant the ability to edit such posts to roles that wouldn't normally have it, which is the position you are in.
If you can alternately edit the custom role permissions directly such that they can edit the posts in question by applying the edit_others_posts permission, then great, you found what is required to let them manage such posts without having to manage the posts explicitly with Access.
No bugs, that's just what's expected if you don't want to manage the post types with Access.
