[Escalated to 2nd Tier] Cannot delete relationship with cred-delete-relationship unless I am admin

[Author]

Posts

[smileBeda]

I am trying to:
Delete relationship with cred-delete-relationship as custom user role

I expected to see:
Link to delete relationship

Instead, I got:
Nothing, it is not working, only admins can delete relationships and there is not even a Access setting for this.

How would the user now delete relationships as he does not want to give admin rights (for good reasons) to anyone?

[smileBeda]

same issue, never resolved properly - the user discovered how to mess with user permissions, which is a very bad idea all-together.
Giving manage options to a user just to remove a post connection we explicitly want to give that user (and which should have its access setting or at least respect the delete posts setting...) is a very bad idea.
This is how sites get hacked later, because users who shouldn't have do have permissions that no one wants the to give 🙁
https://toolset.com/forums/topic/cred-delete-relationship-shortcode-dont-work-with-non-administrators-users/
https://toolset.com/forums/topic/how-to-delete-related-post/

While it is stated to be solved in Toolset Forms 2.6.3 https://toolset.com/errata/non-administrator-users-cannot-disconnect-related-posts-using-the-delete-relationship-links/ this is not what we observe.
We have 2.6.9 and it is still happening exactly as shown on those tickets.

[smileBeda]

Checking out the code I can see it is now hardcoded to edit_post capability.

Even if my user does have edit post caps for the post types, it doesnt allow to delete the connection since one post returns false for cap check the other true, despite the fact that both posts have been authored by this user, as well as connected by this user.

[smileBeda]

So this is the issue.

When access sets a PUBLISH right to any post type for the post types in that relationship (NOTE, not the Toolset Forms permissions, but the actual Post Permissions to PUBLISH), then the edit_post check that CRED does to delete the relationship will return true.
In my case, one post type had PUBLISH rights for that post type and role, the other post type in the relationship did not. Thus, the check failed, and the delete/disconnect link did not show.

This is however managed very badly I think.
First, PUBLISH Rights have nothing to do with EDIT rights or capabilities of (own or other) posts, I think. Not for nothing there are distinct settings for that in Access.
Second, we do not want to give publish rights to a user who is supposed to do things with CRED. This is what front end forms are there for, to let users do things they cannot or are not supposed to do in the backend. And for reasons, we may want a user to be able to EDIT, but not PUBLISH things. I believe I have mentioned and reported this mess a few times already - access here and there deliberately decides that POST rights are used for Front end FORM rights.

In any case, edit means edit, publish means publish, I think we can agree with that.

Even if that gets fixed or explained somewhere, we still have a hardcoded cap in the code, which likely should rather be a Access cap for the specific "disconnect related posts with the CRED link".
That is a new feature, I know, but seen that there is no doc at all describing this issue or how to fix it or how to even make people able to disconnect related posts with CRED, and I just spent several hours debugging this for free, I think this missing feature is very much at least a very urgent one, rather than a missing feature it is more a bug, actually, IMO.

At least, the Erratum could be updated with the information as of how this is supposed to work, since I couldn't find any hint at all anywhere and it is also not intuitive, since for everything else, we can follow "normal GUI" settings and common sense.

Cheers.

[Christian Cox]

I agree, this is unnecessarily confusing. It is my understanding that a User must have the edit post capability for both post types in order to be able to use the cred-delete-relationship shortcode, but I like the idea of having a separate capability specifically for this feature. As you said, the permission should be Forms-specific, not necessarily based on the User's ability to perform similar functions in the backend. The current requirement isn't very clear anywhere. I have asked the Documentation team to update the course lesson for managing relationships on the front-end: https://toolset.com/course-lesson/front-end-relationship-forms-for-connecting-posts
This course should be updated to include information about how to delete an association using the front-end cred-delete-relationship links. It should also mention the requirements for capabilities needed to use these links.

The Erratum post's comments are closed, but I will ask Nigel if we can add one more comment with a statement about required capabilities and a link to the updated course lesson.

Adding a capability specific to this Forms feature sounds awesome, and will require a feature request. We ask you to file feature requests in the front-end request form here (yes, this has changed again recently): https://toolset.com/home/contact-us/suggest-a-new-feature-for-toolset/

We have a ticket filed already to review the usability of the whole cred-delete-relationship workflow, as it is confusing and not well documented anywhere.

Also, supporters are currently putting together a list of commonly asked questions / common problems, and we will be creating sandbox site solutions for those problems for clients to work through or use as a reference. This relationship delete process is one of my suggestions. Documentation is sorely lacking, there is no block specifically available for this delete relationship link, and the relevant shortcode name has already changed 3 times. Needless to say this needs to be addressed, and I think a sandbox demo will be helpful.

[smileBeda]

Hi Christian, thanks for the update and asking DOC Team to put something online for us to chew.

Just to be clear, Toolset Forms checks

current_user_can( 'edit_post', $related_item_one );

That would intuitively mean, that it requires EDIT permissions for both posts on both ends of the relationship (be it M2M or not).
However, it is NOT enough to give EDIT Permissions (be it edit own or edit others) in Toolset Access for those post types. We have to give it PUBLISH permissions.

So while I kind of can live with Toolset Forms asking for EDIT Permissions, I kinda have a hard time believing that PUBLISH rights should somehow influence EDIT Rights.
Of course, if we give Publish rights we automatically give edit rights, but that does not mean, that giving Edit rights does not give such edit rights 🙂

And clearly that is what happens. Even if Access sets EDIT (own or others) for this post type, this does not satisfy Toolset Forms Check for

current_user_can( 'edit_post', $related_item_one );

I have not dug deeper why this is, but if things where "right" then at least, giving "Edit own" access rights, and then attempting to disconnect two (own) related posts, should work, but it does not. Only after Publish rights are set, it does.

And here it gets real confusing, because assume you attempt to disconnect a post that is yours, connected with one that isn't yours
Well, those publish rights now are not enough anymore. Now you need publish rights AND edit others.

Thus there is some mess here, I presume in Access, rather than in Forms.

I have submitted a feature request for the actual best solution to this problem, which is to simply listen only to a custom cap.
However, not sure how many sites already use the "Works! My issue is resolved" solution of mixing some access rights arbitrarily until some mix works... and changing that, might break some setups.

Can you confirm that you also need to set Publish rights (instead of edit rights as expected) in Access to make it work?
And that would be a bug, right? We expect edit rights, not publish.

[Christian Cox]

Hi Beda, sorry for the delay. This one slipped off my radar somehow. Yes, I can confirm that both the Publish capability and the Edit capability (either Edit Own for both post types is required in order to see the cred-delete-relationship link appear on the front-end of the site. Let me ask Nigel if this is a bug or if it's my misunderstanding of the requirements outlined in another ticket. I'll let you know what I find out.

[Christian Cox]

Escalated to TSSUPP as a bug, and Nigel is investigating. His initial investigation does indeed show the problem is caused by Access, as the user_can function returns false for the edit_post capability even though this capability has been granted in the custom Role. I'll keep you posted here as I receive more information.

[Christian Cox]

Okay I have some feedback from Nigel:

In sum, when you grant Edit Any and Edit Own privileges to some lowly role for, say, the thing post type, that does not also grant the underlying edit_published_things WordPress capability, and maybe it shouldn't.

If some user is not allowed to publish posts of some type, then who says they should be able to edit already published posts of that type without approval of some higher role? If you trust them to edit live content, then trust them to publish live content. Without the edit_published_things capability they cannot even edit their own published posts, but that just falls out of how this works, based on WordPress's underlying permissions.

So I think this is actually a won't fix, and arises from a misunderstanding on the part of users and supporters about how this should work, and I'll edit the erratum accordingly.

Now, that said, many people want to be able to give "full" edit rights to lower roles without also giving them publish rights. The solution then is to use the user_has_cap filter and manually add the edit_published_things or equivalent capability.

He has updated the erratum post with a user_has_cap filter-based workaround:
https://toolset.com/errata/setting-the-edit-any-post-permission-using-toolset-access-doesnt-allow-editing-published-posts/

[smileBeda]

>then who says they should be able to edit already published posts of that type without approval of some higher role?

The Toolset Access plugins says that.
Me as the webmaster decides that in the Access settings by explicit settings. It says "edit any" and edit any it is.
I don't see why this should encompass a "maybe I meant only ... what exactly?"
The setting is clear. It says edit any.
Not edit published, or drafted, or theirs or mine only.

For that, there are other settings. Namely, "Edit own" for example.

Editing a post is not equal publishing it, even if it is already a published post.
Specially since this is all related to CRED Forms and not Backend, keep in mid we are not discussing backend things here but things that backend Access settings affect in the CRED front end, which is another unexpected thing.

Further, this is about relationship management in the front end.
Again not related to backend, and is clearly suggested by the entire Access GUI, that you can control these things separate - CRED forms are/is one setting and backend another.

I find this confusing, at least, if the GUI tells me without further hint that I can do "something" when instead I actually need "something else".

[Nigel]

Hi Beda

The feedback Christian shared really related to Access settings rather than the cred_delete_relationship shortcode, which is affected as a side-effect of how the Access settings work.

Ideally we would offer more granular control in the Access settings as relates to edit permissions, but any such changes are probably a long way off.

For now, I've ticketed updating the UI so that it is clear that Edit Any and Edit Own do not apply to published posts unless you also grant Publish rights. That should help eliminate the confusion.

But there will still be clients that don't want to grant Publish rights, and that's where the workaround in the erratum comes in.

As for cred_delete_relationship, its visibility is based on the current user having edit rights over both connected posts, but that is tested using user_can( 'edit_post', ...), which fails if the user does not have publish rights, too.

That doesn't make sense, and is an oversight on the part of the developer, who probably didn't appreciate how the Access permissions work because of the same confusion that has confounded the rest of us over the years.

So we also have a new ticket to change that to something more sensible (either continue checking edit permissions without relying on publish rights, or checking if the user has delete permissions instead).

Again, in the meantime, you could use the workaround described in the Access erratum for the issue of the visibility of the cred_delete_relationship shortcode.

Hopefully that clears things up.