CK Editor Build (not classic): Change toolbar items based on a users permission level

[magnessjo]

I believe this functionality was introduced for Redactor. It's the ability to hide/show certain items on the toolbar based on user groups. For Redactor, the configuration lives primarily in Craft or JSON configs. CKEditor requires inline customization (unless I am misunderstanding). In other words, for each editor instance, we need to pass an object in JS to initialize it.

I created a playground (gross code) for me to explore and learn more about it. My long-term goal is to be a builder that will take in environment variables and spit out a CKEditor configuration. I will add additional tickets for some other questions regarding it.

For this ticket, my question in code can be viewed here. I am querying a relative URL (maps to a controller in my module) to return if a user is a superuser. This isn't an ideal solution for tons of reasons, but the obvious reason is that it isn't scalable (required URL be available on all of our sites).

I am wondering if there is a better way? Is the current user's group-level exposed on window.craft? If not, could it be? The end goal for me to be able to change the toolbar based on permissions. I'm not sure what the best way to do it is.

Curiosity question: Is the JS for the admin panel still built with Garnish?

[brandonkelly]

Redactor allows you to disable the HTML (view source) button for non-admins.

We could consider bringing that to CKEditor as well. Not as much of an issue here though, because CKEditor is a lot more strict about what HTML is allowed to be added in the first place. So the Source button is pretty harmless compared to the damage it can do in Redactor.

Version 3.1.0 is adding a new craft\ckeditor\Field::EVENT_MODIFY_CONFIG event, which could be used to alter the configuration based on user permissions, via a plugin or module. (612c1c5)

[magnessjo]

@brandonkelly - I haven't dug into the new update it but for consideration: If CK allows for transitional tags to be added via source (example: H*) then our preference would be to disable the HTML for non-admins. For accessibility concerns, we disable the HTML button for all non developers/admins.

Thank you and the team for getting version 5 up and going.