developer-rocha → created an issue.
The patch
developer-rocha → created an issue.
In case the Merge Request hasn't been created, follow the patch.
developer-rocha → changed the visibility of the branch 3480164-error-call-to to hidden.
developer-rocha → created an issue.
@fishfree -Which provider are you using? Could you check the browser's network log?
Have you made the right settings for the text format?
You can check this video by @marcus_johansson
https://www.youtube.com/watch?v=CUjZ4HQTZ14
I could not to replicate the issue.
Hello @marcus_johasson - I created a Fork for the issue about field Format.
I ran a few tests and was unable to bypass the original prompt during translation. Drupal itself already has some filters to prevent malicius tags. However, we could implement another layer using Xss in the translateSingleText function or even in translateContent. What do you think?
Hi @marcus_johasson
Excellent point! I'm going to test and create preventions against that.
And yes, I'll do a fork instead of a patch
@marcus_johasson - You are right and your solution works for me. Thank you!
The correct patch.
developer-rocha → created an issue.
This patch addresses an issue when accessing the ai_automator_status field within the AutomatorFieldData.php file in the ai_automator module. Previously, the code used $entity->set('ai_automator_status', AiAutomatorStatusField::STATUS_FINISHED) to set the field status, which caused inconsistencies during the queue processing.
The proposed solution replaces the field-setting method with a direct assignment, i.e., $entity->ai_automator_status = AiAutomatorStatusField::STATUS_FINISHED. This change ensures that the field is correctly updated when the queue status is changed to STATUS_FINISHED or STATUS_FAILED, maintaining the expected system behavior during entity saving.
This adjustment improves stability and consistency in handling the ai_automator_status field within the queue processing.
@marcus_johansson - The buttons were actually hidden. However, I think we should put a default option where the scroll works on the entire modal. I've made some changes to the CSS to ensure that the scroll works on the entire modal and not just on the ui-dialog-content and I've also adjusted the CSS that is applied to the ui-dialog-content, changing the height to auto instead of a value calculated by the total height of the modal.
I created a patch for this.
@marcus_johansson - I have the correct configuration. But I've noticed that whether it's translating, creating text or changing the tone, my modal doesn't show the generate button. Therefore, I believe the problem is related to the Modal form. I'm going to investigate further to try to find out the reason for the problem.
I'm using OpenAI / model: gtp-4o
developer-rocha → created an issue.
In version 1.0.0-alpha7, the issue with the "undefined" message still persists. Additionally, I'm encountering another problem: I can no longer generate any results. When the modal opens, a select input appears for choosing the tone (taxonomy term), but after selecting an option, nothing happens. No logs are generated regarding the error.
I couldn't to reproduce this issue in the version 1.0.0-beta1
I've updated the latest patch with @ddavisboxleitner's comment about dispatch.
Remove the link template "canonical" in the WebhookConfig entity solved the issue. The same issue and same solution of https://www.drupal.org/project/entity_browser/issues/3410285#comment-154... 🐛 Remove canonical link template in EntityBrowser entity annotation because it has no canonical route Needs review
developer-rocha → created an issue.
I have corrected an error in the fetchmodels function. First we have to confirm that there is an OpenAi Secret Key configured.
I've made an update to the patch. Fixed a problem with the moderation state.
I did a update in the solution.
I added functionality to pass the value of `$model` from the ckeditor form submission to the Controller method. This involved modifying the controller method `getimage()` to accept the additional parameter `$model`and updating the call to the `getImage()` method in the `GetAIImage` service to include the `$model` parameter. Additionally, I ensured that the value of `$model` is present in the data received by the endpoint that calls the `getimage()` method.
I created a patch for this issue.
The patch I created isn't solving the problem properly. We already have some solutions on this other page https://www.drupal.org/project/drupal/issues/3343670 ✨ Allow to merge AjaxCommands inside of AjaxResponse Needs work
I did a patch to change the method setCommands to getCommands that exists in AjaxResponse.php and it's works for me.
developer-rocha → created an issue.
Hi @tim-diels, you are welcome!
As we talked privately, your suggestion to remove the language form solved the problem.
The patch for this.