Permissions update: Get rid of remaining checks on ROLE_ADMIN

[simongroenewolt]

Searching in the Bolt sources leads to a couple of 'direct' uses of the ROLE_ADMIN role to check for access. This should be updated to a check against a (new?) permission listed in permissions.yaml to make these developer-configurable.

Below a list of controller classes that still need to be updated. I think most are easy to fix as long as someone decides what the name of the permission should be or which existing permission can be used.

ContentLocalizationController.php

• /edit_locales/{id}

MediaController.php

• /media/crawl/{location}

MediaEditController.php

• /media/edit/{id}
• /media/edit/{id}
• /media/new

EmbedController.php

• /embed

FileListingController.php

• /list_files

[simongroenewolt]

/edit_locales/{id} is needed when editing multi-language entries. In think this means the permissions should match the contenttype's edit permission. You cannot switch the locale when creating new content, so 'create' permission isn't needed.

FIXED

[simongroenewolt]

MediaController.php: /media/crawl/{location} doesn't look like it is being used anywhere.

[simongroenewolt]

/media/edit/{id} is used to edit metadata of images etc. -> create separate permission I'd say.

I think /media/new is used to create a new crop of an existing image? @bobdenotter or @I-Valchev can you maybe explain this use? In my version the label of this action is 'edit attributes'.

FIXED by introducing permission media_edit

[simongroenewolt]

/embed allows you to get some data (title?) so you can embed a youtube (or other?) video, the call itself doesn't change anything, it just responds with a bit of json. -> create separate permission I'd say, but maybe don't call it 'embed' as that would suggest this permission is to set 'embed' fields, but that is dependent on the content-type permissions.

FIXED by introducing permission fetch_embed_data

[simongroenewolt]

/list_files -> pick previousely added files to link to content. Needed whenever you edit content, but we don't know the 'context' so I cannot check for a specific content-type permission -> add global permission, maybe managefiles:files_list, although that might suggest it is part of the 'managing' of the files instead of the choosing.

FIXED by introducing 3 permissions list_files:config, list_files:files, list_files:themes as the list files can be called for all 3 locations. I think only list_files:files is actually expected.

[simongroenewolt]

Closing this issue: All the changes mentioned have been done and merged.