🇺🇸United States @CoffeyMachine

@mandclu I love these ideas.

I haven't yet had a chance to do much work with AI Automators/workflows and these more complex & business-specific use cases.

I could use some help on this one. I'm happy to review MRs.

@thejimbirch Permission is currently controlled by the Image: Create new media or Create media permissions which can be granted or revoked for different roles.

I think you're asking for the ability to allow an editor to upload an image, but not be allowed to generate an AI image? Yes?

I'm not sure how much value this would add since the workaround would be there: the editor could just upload an AI generated image from another system. And then we lose out on the benefits of doing this within Drupal: e.g. having the filename note that the image is AI generated, control over providers/models, etc.

@thejimbirch I'm not sure I understand. The generate section does replace the upload section.

In your example wouldn't you want the caption field to still appear for a generated image?

Have a look at your field weights. The generate section has a weight of 2. If you are adding custom fields and want them to appear below the generate section, give them a weight that is higher than 2.

@thejimbirch The provider configurations are handled by your provider module and the AI module. This is outside the scope of AI Media Image.

Nice catch, thanks @kevinfunk. Merged.

coffeymachine → made their first commit to this issue’s fork.

This can now be done with
https://www.drupal.org/project/ai_media_image/ →

https://www.drupal.org/project/ai_media_image/ →
Generate an image using a prompt to the AI provider's text-to-image model and save the image to Drupal’s Media Library.

IMO, AJAX error messaging could use a few improvements:

1. Echoing s_leu, having the option to put the xmlhttp.responseText would be immensely helpful.
2. AJAX callbacks need a way to be able to act on PHP exceptions. Consider when Guzzle returns an API error response. The go-to behavior is to throw an exception and log it to the console. AJAX callbacks need a way to translate these error responses into human-readable messages. Perhaps we should look at the ExceptionLoggingSubscriber class to see if it's feasible to add a hook or some other means of giving the module developer the ability to act on an exception thrown by another module.

Thanks for hosting, looking forward to diving in.