[Escalated to 2nd Tier] Cannot Upload Media to CRED even if upload_files is true + can see others media

[Author]

Posts

[smileBeda]

There are two problems in CRED "Include the Add Media button in the rich text editors from this form" setting of which one is relatively urgent and shows stopping for our project (unless there is something crucial I miss which we can resolve).

1. Create a Toolset Form for a Custom Post Type and ensure "Include the Add Media button in the rich text editors from this form" is selected
2. Insert that Form to a page
3. Create an Access Custom User Role (copy of subscriber) and give it upload_files permissions, as well as permissions to create new posts with above form, as well as make sure the "Use any Media Library file when adding files to front-end Post Forms" for this role is NOT selected.
4. Visit the page with form using this user role and find the following issues:

A) You can see the Media Upload Button in the WYSIWYG of post body but you cannot upload media.
The error will be "Sorry, you are not allowed to attach files to this post."
However we have given the user upload_files rights which is what is required according CRED inline DOC in the Form Builder.

B) You can still see media uploaded by other users, which you shouldn't.

Issue A) can be resolved if you control Media Post Type with Access as well and give the custom user role Publish rights on it.
However this is unexpected, and not mentioned at all in the CRED inline hints/doc of the media settings. I think it should at least be mentioned, but rather would expect this to be handled automatically, after all, we give the user specific Access rights over the FORM and the FORM MEDIA access settings are what control the front aspects, so we may even want to have different rights in the backend. Perhaps this is a feature to be added instead, however steps documented (unless I miss something) are still straight on leading to a "does not work" situation.

Issue B) is so far not resolved and much more critical, I can still see others people media and that is a privacy issue.

We would appreciate if the can be looked at and perhaps fixed or communicated how to resolve it (as this project is, as in the previous tickets, affecting numerous SaaS sites built with Toolset, we would appreciate if we could resolve this quickly)

[smileBeda]

Well, no.
While issue A) was resolved on my local test as above described it is not working like that online, and on addition, it anyway shouldn't, because Access says "This section controls access to media-element pages and not to media that is included in posts and pages." when setting media permissions.

So, back to booth issues are showstopping and urgent for us, not just one.

[Minesh]

Hello. Thank you for contacting the Toolset support.

Regarding issue A:
- After following the steps you shared, I was even not able to upload the image
- But as soon as I given the "Publish" permission to the custom subscriber role for the custom post type that is used by Toolset form, I'm able to upload the image.

Regarding issue B:
- It's been escalated and I'll get in touch with you as soon as I've updates on it.

[smileBeda]

Hi Minesh

- But as soon as I given the "Publish" permission to the custom subscriber role for the custom post type that is used by Toolset form, I'm able to upload the image.

This is not a solution.
We do not want to touch BACKEND permissions of a user when we really want to control their FRONT END permissions only.
And our user HAS frontend permission to add such posts, but of course, they have no BACKEND permission to do so.

This is the entire purpose of having a Front end form in many cases, to avoid users having backend permissions, and that is broken it seems to me.
If I need to give backend permissions to use front end forms I can as well use backend - especially that we must remember, users can add posts just fine without any backend permissions, it is just the media that breaks and that is completely unrelated to "post permissions" in the backend, strictly speaking.

Could you please revisit this?

I am also pretty sure this was working prior to April 15th release. Not confirmed, but since the client tested together with me the entire product prior to release, and we couldn't see the issue, now we can, this speaks for a new set of bugs introduced with the last releases.
PS I already tested with Beta CRED which did not resolve the issue.

[Minesh]

I got it. We are trying to figure it out for now. Please hold on for further updates on issue A.

[Minesh]

Our 2nd Tier(Nigel) checked with the previous version and he do not find it working. He confirms that he run a test versions back to Sep 2020 which behave exactly the same as currently.

However, we file the internal ticket to improve this behaviour, I'll get in touch with you as soon as I get any updates on internal ticket.

For now, the workaround would be to grant post type access using Access plugin as shared and you can add some custom code to remove the post type listed on left admin panel or there are number of plugins available which you can use to block admin access for specific roles.

[Minesh]

Hi Beda,

I got the news from Devs as follows Regarding the issue A :

The Access setting that grants this role the ability to use the form just does that: lets you use the form and submit it, regardless the post type managed by the form. In fact, you can change the form later and make it submit a completely different post type, and the Access setting for the form will not change. In other words: the Access setting for forms does not modify the edit/publish capabilities for a given post type, because for Forms, all users have the ability by default to create or edit a given post. The Access settings limits that ability.

Now, the Media button on WYSIWYG editors is produced by WordPress, and it depends on the ability to manage attachments form the current user, and that defaults, if no specific Media post type is set on Access, to the capabilities for its parent post type, which is Posts. In other words: the Media button will appear if and only if the current user can manage Media post type which usually inherit this capability from Posts.

Currently, there is no way to grant access to the Media button to users without the proper capabilities, because this button let's you create or edit posts of another post type. Hence it must remain an independent setting from the one that grants access to the form itself.

So, it will remain as it is and there is no fix proposed.

[smileBeda]

Thanks Minesh for the update.

Giving the rights to add/edit MEDIA post type does indeed resolve this issue when we use the "Use the WordPress Media Library manager for image, video, audio, or file fields ".

That, is for the custom fields and featured images for example.

The _same_ Media Uploader thus allows to upload and add media to a form when we do it in a Custom Field or Featured Image, by giving Media Edit rights.

However it does not_ allow to do _the same action in the same media uploader, when it comes to adding the media in the rich text editors_.

In that case, we must give edit/publish POST rights.

I have tested the above after your message, and those are the results I saw.

This is certainly _confusing_, if not suspicious to be a bug or implementation error.

If anything minimally this needs a clear GUI that either sets this for us or warns us in each of the Hints (with Hints I mean the hints/tooltips) for both checkboxes that allow us to:
- Include the Add Media button in the rich text editors from this form
- Use the WordPress Media Library manager for image, video, audio, or file fields

PS:
In my past time as a freelancer I learned there is no such thing as "not possible". So I would even disagree that it is _necessary_ to give the users those rights manually in Access, I bet it is possible to give attaching capabilities and upload capabilities on the fly if we include/check something in the forms, which would avoid any user to ever say "it is broken"
However, that is another discussion.

I think a "hint" update would definitely be required.

Please let me know if I miss something.

Thanks!

[smileBeda]

It gets much worse than that. Not sure why I did not see that before.

Why are we even using Access in these tests? I just found out that in a form where both "Include the Add Media button in the rich text editors from this form" and "Use the WordPress Media Library manager for image, video, audio, or file fields", both features, being precisely the same features, act 100% different.

1. Use the WordPress Media Library manager for image, video, audio, or file fields
This works JUST FINE without any user role that has upload files rights. It works JUST FINE without any Access settings. It works JUZT FINE as long the user is logged in. The media IS UPLOADED even if the user has NO UPLOAD RIGHTS, before even the form is submitted.
2. Since this happens in the very WP Media Uploader, which is the precise same instance as it is for the "Include the Add Media button in the rich text editors from this form ", we would expect that at least without access, the feature would work the same. It does not. The button does not even appear for users without upload media rights, even thou, we clearly see in #1 above that upload rights are NOT required to upload media with the WP Media Uploader, OR, that something adds/fakes those rights for us behind the scenes, whichever it is, the fact is that both media uploader instances do not work the same, while they are definitely the same instances, and both do the precise same thing.

So I am not convinced that this is all expected. Even if it is, it screams for a much clearer GUI and/or DOC, since even Toolset support was not able to tell me how it works half a month ago and required Developer insight to tell me it is expected, I would say that is a red alarm bell and should immediately trigger the "need much clarification" bell, of course, only if you are interested in improving the plugin.

Thanks!

[Minesh]

Please allow me to re-discuss this with Devs and I'll get in touch with you as soon as I know more.

[Minesh]

I got the update that:

The "Add Media" button displayed over the WYSIWYG editor is managed by WP itself, it generates it when printing the editor, and it does its own capabilities checks to include or exclude the button. We checked it a number of times before: it can not be modified.

For image, and in general for file-based fields, we control the button, the request it generates, and we can grant capabilities in a "contained" way. But that "Add Media" button over the WYSIWYG field is outside our control.

In short because WordPress generates the WYSIWYG field and manages the ability to insert media, while the custom image fields are managed by us, and hence we are able to make the WP Media Uploader work differently than the "Add Media" button displayed above WYSIWYG.

[smileBeda]

Thanks for the update, Minesh.

My problem persists that:

1. when I enable "Include the Add Media button in the rich text editors from this form" it says:
Add Media button
This form might contain WYSIWYG fields.
You can enable its Add Media button on them, for users with the right upload_files capability (by default, authors and above).

That is not how it works, as you confirm yourself above.

It is not based solely on the uploa_files cap, as you confirm yourself above, instead we also need to give certain unrelated rights in Access for the user.
i.g publish posts rights and media rights, at least, according to my testing, but then, testing is not really my job, so I leave that to you.

I just know that it does not work the way it is described in the GUI, otherwise I would not be here.

2. when I enable "Use the WordPress Media Library manager for image, video, audio, or file fields" it says:
This form might contain media fields (image, audio, video, file fields).
You can enable the native WordPress media manager on them, so logged in users can select multiple items at once in repeating fields, and also edit images.

That is indeed hw it works as long we do NOT use Toolset Access.
As soon we use Toolset Access, it does not anymore work as stated in the GUI and we need to enable media upload settings in access, at least, according to my testing, but then, testing is not really my job, so I leave that to you.

I just know that it does not work the way it is described in the GUI, otherwise I would not be here.

In either case, we do not find Toolset to be doing what it states in the GUI.
In both cases, unexpected and undocumented steps need to be taken to make it work and at least in one case it seems obvious that Access is making things "happen", not WP.

Concluding, I don't think it can be that a user must (no matter how advanced or beginner the user is) come to the forum and wait for 16 days for an answer that is describing an "expected" solution.

But that is of course not up to me to decide, for me, I won't care since now, after 16 days and several hours of testing and discussions I do know how it is "expected" to work for issue A).
For issue B), we await a fix and will then once it is fixed update the client sites.

Thanks

[Nigel]

Hi Beda

Minesh asked me to step in here.

The issue with users being able to see media that are not their own in the media uploader is escalated, but we don't have any progress to share yet.

The other issue relating to the visibility of Add Media button on WYSIWYG editors, I've just re-tested (again) and it works as described in the GUI. Users with a role of author or above will see the button (and can use it); lower roles won't see it (and we can't fake it for the WYSIWYG field, as explained by the devs) and need additional permissions.

If you use Access you can grant the lower role permission to publish the post type being created with the form and that would be sufficient. (That seems like the least problematic option, you are simply granting the same back-end rights as you already give in the front end.)

Or you can update the permissions for the role using Access and grant them upload_files capability—as described in the form GUI.

That also works.

Sorry, but in testing everything works as expected and as described in the GUI, I don't believe there is anything for us to do here.

We'll leave this ticket escalated for the first issue.

[smileBeda]

Thanks Nigel, however that is not what I see.

I see the GUI for both features telling me A) needs to be done, but I need to do A) and B) and C) and I need 16 days to find out that I need to do that because not even experienced Support knows, to make it work.
I see the second feature doing A) when Access is disabled and B) when it is enabled. Again this is not how I expect things to work in a user friendly manner specially when there is no hint in the GUI.

That, for me is a red herring.
If it is not for you, for me it's fine since now I know how this is "supposed to work".

I don't want to spend more of your and my time on this topic, thus feel free to re-escalate directly (assuming the ticket will be put back into your pending queue due to my answer)

Thanks.

[smileBeda]

Right now, I needed to give the user Media Publish rights, Custom post publish rights and file upload rights, to get them to upload media when creating a new post in the front end.

Unless that done, it always turned to be "error you have no permission".

I noticed thou, that meanwhile the user at least cannot see the "others" media anymore. So there is progress, I guess.
Yet this is all but "nothing broken".

I guess we have behaviour #3 now, a year after reporting it. I will update again here once I have another behaviour, since I regularly have to come back to this thread to see how it is actually done.