User tests: Successful: Unsuccessful:
Thanks to @stutteringp0et for original PR.
This small change allows media fields to be used in user profiles, where a user is not authorized for core.create in com_users - they can be authorized in com_media. In conjunction with a filesystem plugin, a user can be granted access to com_media a limited area of the filesystem. This change should not impact anything other than front-end media modals.
Currently the change:
A future addition / feature enhancement would be to limit user to only viewing their own media and limit uploading to just a folder for that user.
In plugins/fields/media/media.php
if com_media has core.create permissions, enable the select button.
In components/com_media/src/Dispatcher/Dispatcher.php
add a check to see if the user has permissions for core.create on com_media
Create a user custom field of type media with Registered access level permissions.
Editing your profile, the media field will have no button to open the media manager a Select button, but will not load the Media Manager when clicked because the user has no access.
Apply this change
Go to options for Media
Change the permissions for the "Registered" user group, setting "create" permissions to "Allow".
The user is now given the "Select" access to the Media Manager when they go to select an image.
Media manager will not load due to permissions issue
Media manager loads due to Registered Users having core.create permissions set on com_media
Status | New | ⇒ | Pending |
Category | ⇒ | Front End Plugins |
Labels |
Added:
?
|
Category | Front End Plugins | ⇒ | Front End com_media Plugins |
Title |
|
@particthistle PR #19038 was for the 4.1-dev branch and this one here is for 4.0-dev. Is that by purpose?
Thx, done
Title |
|
Labels |
Added:
?
Removed: ? |
4.0 instead of 4.1 was an oversight.
JFactory changed to Factory
@particthistle As far as I could see, the other PR just removed obsolete conditions, and only this here allows the registered user access to the media field, so both PRs are independent. They could have been made together in one, but keeping it separate makes testing safer because only the relevant change is tested, here the new access and in the other PR that removing the obsolete stuff doesn’t break anything.
I have tested this item
I have tested this item
Status | Pending | ⇒ | Ready to Commit |
RTC
Labels |
Added:
?
|
Status | Ready to Commit | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2021-11-25 09:54:57 |
Closed_By | ⇒ | bembelimen |
Thx
@particthistle PR #19038 was for the 4.1-dev branch and this one here is for 4.0-dev. Is that by purpose?