Thank you all for this! Last issue before 1.2.0 release hopefully!
This change should go in, otherwise the uninstall/install will not work, unless we make the config optional as far as I could test.
Ok, we are on 100% track with the releases, so this is getting merged into AI Agents as well for 1.2.0 release. Thank you everyone!
This will happen in 2.0 I think, but we can do an update script for it then.
The AI Translate module should take care of this now.
marcus_johansson → created an issue. See original summary → .
marcus_johansson → created an issue. See original summary → .
We should probably discuss if this belongs in the AI core module or even in its own contrib module. It seems like a reoccuring use case for at least AI.
Testing is done and It's working correctly.
If I only set "Create AI translation" and no Content Translation permissions:
- the page is forbidden
- the translate tab doesn't show up
- it does not show up on the content overview page
- you can't use AI translate
If I only set "Create AI translation" and the specific content type:
- the page works
- the translate tab shows up
- it does not show up on the content overview page
- you can use AI translate
If I only set "Create AI translation" and the specific content type or "Translate any entity":
- the page works
- the translate tab shows up
- it does not show up on the content overview page
- you can use AI translate
If I only set "Create AI translation" and the specific content type or "Translate any entity" and "Create Translations":
- the page works
- the translate tab shows up
- it does show up on the content overview page as an option
- you can use AI translate
So the only thing I can think about, is that it should maybe show up a link on the content overview page if the "Create AI Translation" + the specific content type or any is set.
OR I think is needed for backwards compability, so we do not lock out people with an update.
So looking goof from my side!
marcus_johansson → changed the visibility of the branch 3550731-ai-prompt-does to hidden.
Yes, I think for 1.2.0, move the trait there. I think the methods names should be a little bit more specific, so there is no future collision with some other download, delete etc. So maybe FileDownload, FileDelete etc.
There is an Enum where we set model capabilities that we could use to set a new capability for file upload. From what I have seen not all OpenAI models supports it, so it should be on the model level.
That way we can have checks where the standard is that its not supported, and OpenAI for now supports it.
We can start to move to Symfony interfaces, but they will not be stable by end of year asfaik. So 3.0 is probably when we move fully.
There are features that never made it into 1.2.0, so we could have a 1.3.0 with a shorter lead time, smaller new feature set and a lot of deprecation notices at the same time as we work on 2.0.0.
We could also say that modules that gets major overhauls during this time (Automators, AI Search) will not have any new features in 1.3.0.
Thank you, outside of the recipe validation above, I have also tested on doing a large config import, with multiple node type that has automators, by:
1. Importing it all from scratch.
2. On a running website, disable all automators, so the statue field is gone and then re-import it.
It all works great. So this is getting merged!
Tested and working on fairly complex custom fields! I'll set to RTBC and not merge yet, since there is a discussion on Slack where this should live.
Thank you for the fix. Tested with 4.0 and 3.0 and working on both.
Fixed a cpsepll issue that had nothing to do with this issue. Its getting merged now. Thank you Narendra.
marcus_johansson → made their first commit to this issue’s fork.
Thank you Artem - getting merged.
For reference that the tokens are using a common way of writing them: https://project.pages.drupalcode.org/distributions_recipes/config_action...
Makes sense - this module is new, plus the change is so small, that we will merge this even if we are close to stable release.
Tested and getting merged. Thank you @bbruno.
Since it documentation, I'll go ahead and merge my own work.
Reviewed and looks good. Getting merged. Thank you @svendecabooter.
For reference if someone wants to look at the changed types:
- https://www.drupal.org/node/2954832 →
- https://www.drupal.org/project/drupal/issues/3341682 📌 New config schema data type: `required_label` Fixed
- https://www.drupal.org/node/3416240 →
LGTM - will await for Valthebald to look and merge.
Merged - @valthebald, could you set credits, since I don't know who has helped you outside of this thread.
This should be upped to 2.x as a breaking change, right?
The FWA file, was just garbage anyway that should be removed. The whole point was that this can be handled via AI Automators.
Thank you for the last fixes @abhisekmazumdar and thank you all that has been working on it!
This is tested so it works with:
* Removal
* Without FWA installed
* Removeal after FWA uninstallation.
* Form is reachable.
I'm not sure why the new MR was added, but it shouldn't be needed.
Tested and working both single and multiple. Code looks good and documentation. Getting merged. Thanks Artem!
marcus_johansson → changed the visibility of the branch 3543298-embeddings-generation-explorer to hidden.
Setting to release blocker, so I don't forget :)