🇨🇦Canada @_randy

There's a number of options one can do. From setting a process variable to the end time all the way through to creating your own custom task type. Easiest is a process variable that holds the end time.

Seems the DEV release has an updated version where the images and prompt are properly separated. Consider this issue fixed.

_randy → created an issue.

Does the external participant have an interactive task assigned to them? If so, just use the reminder options in the task setting.

If you're waiting on an API response and you'd like to send out periodic emails, you'd handle that in a batch function that only ends when the task is deemed complete.

Template Builder has been updated.

I also have done something like this before, but I set the email task URL to

https://site-url/user/login?destination=[maestro:task-url]

That should work for all use cases I believe as you would first go to the user login page. If you're already logged in, you get immediately redirected. If not, you get the login, then directed to the task url.

Might save you a patch...

@mi-dave: Quick patch to see if that helps -- the DEV release of 4.x should have the updated css that should push the content blocks below the canvas now.

The palette bar overlapping the template will happen on any template that hasn't been panned with the new interface. It's due to the top/left coordinate being the top/left of the interface. You just have to pan it to suit your viewport.

For the footer css issue. We'll take a quick look unless you've got a patch.

Ah, sorry about that. Try 4.2.2: https://www.drupal.org/project/maestro/releases/4.2.2 →

I've updated Maestro to v4.2 (keeping 4.14 active for now). Maestro 4.2 now has the new template builder which completely replaces the original template builder.

Thanks! I'll commit the alternate patch soon to the 4.x branch.

Much thanks for the patch mi-dave, however, I have an alternate patch for this that's probably much simpler.

Give the attached patch a go as it removes any additional complexity.
The simplest solution is to give the hamburger menu and its bounding box IDs and check for those IDs as to not trigger a move.

Just as an FYI: I have in the pipeline a revamped Template editor that is a complete rewrite of the drag and drop interface. So I'd rather go with a simpler patch to fix the existing editor. Let me know your thoughts and if the alternate patch works for you.

That should take care of it.

Update this MR to include the undoing of the already committed idlist parameter optional flag then?

_randy → created an issue.

_randy → created an issue.

See commit here: https://git.drupalcode.org/project/maestro/-/commit/4212069441f5d2689ade...

_randy → created an issue.

@chriszz
I've pushed a fix for this. You can try the DEV release or wait until I roll a new version (coming soon).

Works for Claro and Gin (and should work for other themes as well)

Thanks for the patch. idlist is used, so making it optional for this edge case is fine.

The API and task save needs updates to support map type. "map" type requires an associative array during saving.

I agree with what @robloach said and also agree what was noted in the blog post: https://www.jamesmatthewsaunders.ai/post/ai-ethics-and-open-source-why-w... in that:

The agnostic approach for choosing the AI provider means you can choose which provider most aligns with your business ethics.

In the blog post, the following quote resonates: "AI shouldn’t be about replacing people. It should be a force multiplier. It’s here to help us work more efficiently and solve bigger problems faster" Our Maestro → module AI extensions do exactly that: Use AI to offload the mundane tasks humans do so that they can focus on more productive tasks. However, if a business automates a business process and that replaces people, is that an ethics problem that Drupal must guard against?

The idea of guardrail agents to cleanse inputs is the new-normal approach when dealing with safeguarding your AI-enabled sites. I think it also comes down to education of the community when using new AI tools: Cleansing inputs and creating prompts which do not leak, override/harm your website or otherwise provide faulty information. It's not good enough to assume everyone/everything is a good actor when it comes to using AI. It's a new version of SQL injection for our age.

_randy → created an issue. See original summary → .

_randy → created an issue.

_randy → created an issue.

Added ECA Content to the dependency list as the example installed will require it.

_randy → created an issue.

Glad you were able to sort it out and thanks for posting your solution.

_randy → created an issue.

New entity delete hook implemented for maestro_process.

_randy → created an issue.

_randy → created an issue. See original summary → .

Fixed with the 4.1.2 release.

_randy → created an issue.

It was D11.1.7 on Pantheon. I'm going to redo the site from scratch. If you're not seeing it, then I'll close this issue as it could be something local to the install.

_randy → created an issue.

_randy → created an issue.

Ok. Just to be sure, you see it working in the Claro theme?

We set the modal in code like this:

$form['edit_task_complete'] = [
    // In the UI to be editing.
      '#type' => 'link',
      '#title' => 'Edit Task',
      '#prefix' => '<div class="maestro_hidden_element">',
      '#suffix' => '</div>',
      '#url' => Url::fromRoute('maestro_template_builder.edit_task', ['templateMachineName' => $templateMachineName]),
      '#attributes' => [
        'class' => ['use-ajax'],
        'data-dialog-type' => 'modal',
        'data-dialog-options' => Json::encode([
          'width' => '90%',
          'height' => '100%',
          'dialogClass' => 'modal-task-edit',
          'position' => [
            'my' => 'center',
            'at' => 'center',
          ],
        ]),
      ],
    ];

Where we set the width and height, which is indeed reflected in the outer modal DIV:

<div style="position: fixed; height: auto; width: 90%; top: 26.46px; left: 107.2px;" tabindex="-1" role="dialog" aria-modal="true" class="ui-dialog modal-task-edit ui-widget ui-widget-content ui-front ui-dialog-buttons" aria-labelledby="ui-id-12">

Same DIV output you've shown exists and works in Claro.

Let me know if you've come up with a GIN-specific fix. If not, I'll have to dig into this a bit further.

Mistakenly unchecked @emulamba instead of me when giving credit. Resolved.

Committed to both the 3x and 4x versions.

_randy → created an issue.

Note on the Maestro AI Task API

Enable ECA Model info

Clarification on node_submission Entity Identifier for Maestro.

Added ECA model clarification

New SPV image

Update SPV new helper plugin.

Add reference to Maestro AI Task

Maestro AI Task inclusion

Remove the outdated simplytest.me link.

Inclusion of Maestro Views-based Task Console in version 4.1

Removed simplytest.me link as it was outdated and would require sub-modules to make it even worthwhile.  Watch the videos instead.

Update title

Agentic AI

Update for General settings.

MAT capabilities plugin information updated

Updates for images

Any updates to this issue?

Moved this to 4.x branch.

I'm not sure on your queue implementation, but as far as Maestro's core is concerned, I don't think anything changed in the Maestro core notification routine whatsoever.

Version 3.1.1 worked for you? ( https://www.drupal.org/project/maestro/releases/3.1.1 → )

You turned off Maestro notifications in the Maestro config ('Send out notifications' option)?

Default notifications now use token instead of queueID.

I have also added an install hook and update hook only in the 4.x branch.

Install hook will preset the 2 tokens for orchestrator and sitewide token. It is suggested that you configure those for your own purposes. They are mandatory.

The update hook will update any open task with a token (If it doesn't already have one). If you are manually tracing and changing status of closed processes or tasks, you are responsible for setting tokens on those tasks which are now unarchived and not completed.

Notifications to be updated next.

_randy → created an issue.

_randy → created an issue.

_randy → created an issue.

For anyone else who runs into this problem with this module or any others that provide attributes during the render process:

I found where, not necessarily why, this issue occurs.

This issue manifests itself during rendering of a Twig template specifically when you are looping over view output rows.
If you have a twig template for a specific view and display, you'll probably do something like this within it:

<div class="wrapper">
    {% for row in rows %}
      <div class="output-card">
        {{ row }}
      </div>
    {% endfor %}
  </div>

This worked up until ~Drupal 10.2.9. For whatever reason in D10.3+ in conjunction with this module, you'd get an error thrown about "attributes" being an object, not an array.

The fix for this issue was to change the output in the Twig template to:

<div class="wrapper">
    {% for row in rows %}
      <div class="output-card">
       <div{{ row.attributes }}>{{ row.content }}</div>
      </div>
    {% endfor %}
  </div>

Where you now must output the row attributes separately from the row content.

Thanks to @shelane for poking around enough until I was able to find a solution to the issue!

I agree with @aaronbauman’s comment #32.

An easy way to really see the issue is to:
Create any view, add in some VBO, and turn on ajax. All of the VBO submits will go to the ajax page rather than the VBO actions setup page.

I'll accept the MR for the schema update, however, I'll have to run this through some regression testing to be sure.

If you can rebase with the latest merges, I can then accept these updates.

@shelane
I'll give this a go in the next few days. I appreciate the update and attempt.

I should have pushed my D11 info.yml compatibility a while ago -- apologies for that. I pushed those simple yml file changes for now.

The linted output makes it difficult for me to determine what we're pushing into the repository.

I'll have to dedicate more time to look at the linted output as I see some changes to method/function declarations for nullable types. Perhaps just better shorthand for PHP 7.1+ -- just like some of the replaced is_set(..) with ?? operator.

Or we close this ticket down for d11 compatibility and open a new ticket where we can work through linting and code standard updates sequentially.

I've added 2 screenshots. But I don't think they'll help.

You're 100% right in that this works out of the box (I tried on simplytest.me)

Perhaps this is a Bootstrap5 theme related issue or something in Layout Builder ( https://www.drupal.org/project/bootstrap5 → ).

But it manifests itself first here. I'll have to dig some more.