CKEditor AI plugin button available without permission to use it

The CKEditor plugins don't appear to have a concept of access at the plugin level, so this would probably need to be handled in the aiui.js javascript file, which would need to be able to check the permissions of the current user.

For now as a work around I added the logged in user role as a body class and hide the button for those without the required role :-)

You have failing tests. I thought it might be better to address the issue within the existing JS, but I think this is a fairly elegant solution.

Thank you mrdalesmith
Pipeline is passed. Moving to Needs review

Thanks for the quick action!

I tried the patch, cleared all cache, rebuild the permissions, cleared browser cache but the button is still there for users without the permission to use it.

Do I miss something?

Yeah the patch doesn't work because the form_alter only adds the library to the filter_format_edit_form form, so the javascript never makes it onto the page when content using CKEditor is being created/edited.

I think this may need a rethink @anjaliprasannan - all you're doing is hiding it when the filters are being edited by admins.

Its my bad, I was mistaken that the ticket was to remove the ai plugin icon in the configurations. Now the patch is updated to remove the ai assistant dropdown in ckeditor.

User with ckeditor permission

User without ckeditor permission

Couple of suggestions to improve the code.

There seem to be some commits relating to AI Assistant Block access that have leaked into this MR.

Still not working for me, I'm afraid. Steps to recreate:

1. Clean site install.
2. Enable AI CKEditor with patch above.
3. Update Full HTML text format to use AI CKEditor. Ensure Basic HTML does NOT allow use of CK Editor.
4. Create content type with WYSIWYG field that uses Basic HTML as default format.
5. Create user with permission to use Basic HTML and Full HTML but NOT permission to use AK CKEditor
6. Log in as user and create content with new content type.

The code in the form alter runs when the form is first opened and correctly identifies that a WYSIWYG field is in use and that the logged in user does not have the required permission. However, switching the field's text format from the default Basic HTML (no AI) to Full HTML (uses AI) results in the AI button appearing. There are no errors in console or in watchdog.

The form alter also runs now on every form on the site, even those that can never have CK Editor in use: I think this might be better if the access is checked within the existing CK Editor javascript so that it only runs when CK Editor is present.

I just tried the latest MR and it works in my config because the user that lacks the permission to use the AI function only has one Text filter available. So no switching in text filters.

Indeed, if you give a user permission to use more than one text filter the AI button appears after switching the filter. But a page refresh removes the button again.

Setting back to needs work: the previous comment confirms it doesn't work if the user has access to multiple text formats, so this is not ready to merge. Also needs to address bringing the solution inside the existing JS, and removing the need for the form alter.

@anjaliprasannan - Sorry, just saw that this issue was sending mails back and forth. I think that if you have form_alters that runs on every form with checkups and intervals that might be started on multiple ckeditor fields you can run into performance issues.

I think you need to solve it via the aiui.js and the AiCKEditor.php plugin, since they are both the insantiators of the backend and the frontend.

Check this patch: https://www.drupal.org/files/issues/2025-04-03/ai_ckeditor_hide.patch → - I think that is mostly how it should be solved. Could you check that one and see if that works for you and if you agree with the solution, try to create a (maybe improved) MR with it?

@paul - maybe check if this is close to how you initially thought you would solve it?

Thanks!

@marcus_johansson I tried the patch and it works well! I've incorporated the changes and improved in the MR.

Let me know if you have any feedback or further suggestions.

Yep, looks better and works better :)

Great!

Works well here too. Even with switching text formats. Thanks!

This got a merge conflict that I fixed and rebuilt it, will get merged. Thanks everyone!

Hey folks,

I realize this has been committed already but when I use 1.1.x (or 1.1@beta) of the module, when logged in with a user without the "Use AI CKEditor plugin" permission, I get this error in the console: "ViewModel is not defined", and the whole CKEditor toolbar does not render.

Conversely, when I use the patch in #21, on top of the current stable release, it works correctly in hiding the button without throwing an error.

Hi @shiraz dindar, it could be regression error or that the build did not work. Could you create a new issue and add this issue as related issue?

hi @marcus_johansson,

The thing is the dev release still builds fine and works for users that do have permission.

This is my status:

Version               | User Type          | Toolbar Displayed      | AI Button
----------------------|--------------------|------------------------|---------------------
1.0.5                 | With permission    | ✅                     | ✅ displayed
                      | Without permission | ✅                     | ❌ displayed
1.0.5 with patch #21  | With permission    | ✅                     | ✅ displayed
                      | Without permission | ✅                     | ✅ not displayed
1.1.x-dev (MR merged) | With permission    | ✅                     | ✅ displayed
                      | Without permission | ❌ console error       | N/A

So the issue seems quite specific to this issue (not a general issue with the dev release), and seems specifically due to what happened between patch #21 and the MR. I *could* create a new issue but I think this is the issue with the needed context.

I've pasted a screenshot of the console error here.

Would you like me to test something more specific, or try a certain sequence of steps?

If you still want me to create a separate ticket, let me know, but again I'd end up referencing this one. To be sure, for my own purposes, the patch #21 is working and it's fine for me, but I imagine that once dev gets marked as RC other people will have the same issue as me. At this point I'm surprised it *did* work for the others. There aren't really any other variables for me with this. I repeated my tests when building that chart and the only changes were the versions.

Automatically closed - issue fixed for 2 weeks with no activity.

Here is another patch influenced from MR, which works well in my case.