🇨🇦Canada @_randy

@mably: Sorry for the delay, however, the last batch of updates to your issues, is it just to include patch files? Or is there something new?

Thanks for the MR. However, I have to take a much closer look at this as I'm unsure of why we'd be adding MaestroIf to the schema and removing things like initiator from the template.

Thanks for the patch.

Sure, Maestro could be used for any sort of guided campaign. Maestro is not an SMTP client, so you'd have to consider using a proper emailing service to detect bounces.

The issue becomes one of how anonymous users interact with the system, or if at all.

Keeping in mind that Maestro inherently uses a task assignment to a single actor or to a role, you'd have to consider what a workflow would look like and if your email campaign would create one workflow instance for each outgoing email (sounds heavy). There's lots of architecture to be thought through as out-of-the-box, Maestro is a very flexible tool, but is not an email campaign manager directly.

I couldn't merge your PR for some reason, but I have a fix for that warning that I just posted. Have a look at the approach I've taken to sort out the warning and let me know if it's ok for you.

@Vladimir MS:
Can you determine if this is indeed a user which has been deleted and if altering the template to send notifications to the appropriate replacement user is sufficient?

Placing in Postponed status to determine which is the most appropriate course of action here.

Manually added patch and committed.

Moving to fixed. If this causes issue, re-open a new ticket.

Many people fork the stock Maestro task console and customize it and maintain it themselves. Or use a views-based task console sole with your own custom view operations pseudo field for these types of operations.

We've generally provided this type of functionality outside of Maestro core with some simple custom code dependant on the use case for the customer's workflow and management scenario.

Assignments are stored in the maestro_production_assignments entity table.
If you compare that table against the Reassignment form (maestro/src/Form/MaestroReassign.php) you'll see how we're doing the reassignment by maintaining the assign_type. The assign type will either be user or role.

You can augment the assignment record however you see fit outside of the constraints of Maestro's core.
You could conceivably form-alter the reassignment form to unhide the assign_type and make that a select box and thereby show/hide the appropriate "select_assigned_xxxx" form element. Then add your own submit handler to save the whole entity as in our save routine, we do not overwrite the assign_type.

It's a start for you. Let me know if this helps.

Sorry, yes, you are correct. I had looked at this as if we were swapping the field in the Process entity. I'll commit this.

Not sure I see the issue here.
I have both my manual web test process and the one you provided and both appear in all stock Maestro views.

Something I'm missing?

I have d10.2.3 With PHP 8.2.
Perhaps the PHP version? I'd have to test.

Retaining the custom error markup div for custom requirements as well as potential future use.

Added this quick fix. Kept the status to needs review to be sure this is OK. However, it does indeed look pretty simple as a fix.

Leaving this open as I will need to check installations to be sure this hasn't broken anything.

Looks fine. Re-roll or I can manually add and give credit.

I'm not quite sure of the use case here and how this was configured.

Can you provide an export of the task config? Just so I can re-create and verify that this is indeed something that is a bug or something that should be rectified on save.

I will add an appropriate message.

Correct, you can override views config as you see fit.

Probably also best to not reuse core Maestro views just to be sure.

Closing.

I'll give this patch a go to help alleviate any customization to the base views etc. Just needs a re-roll.

We should hold off on this as this works fine with D10. Adminimal, from what I can see, doesn't yet have a D10 release listed, dev or otherwise, on their project page.

Let's postpone for now, and revisit once we get a release listed.

I'm not sure I see this issue. I only see "ANY" as an option once regardless if it is required or not.

If we were to be a bit more precise, we'd probably do a detection of the filter being required rather than just removing it altogether.

More like this:

$is_required = $this->options['expose']['required'] ?? FALSE;
    if(!$is_required) {
      $options[0] = $this->t(' - Any -');
    }

The task console detects if there is a queue token or not.
If no queue token exists for the task, it reverts back to the original mechanism for launching/executing tasks. Otherwise it will use a token.

I'm not sure if you've set the Maestro URL Tokens ( https://www.drupal.org/docs/contributed-modules/maestro/maestro-api#s-ma... → )

If you've not set the token, Maestro will fall back on the older queueIDs-in-URLs for things like the task console and task URL generation.
There are a couple places where established tasks will save/cache their URLs in the database. This is why I would do what I suggest later on in this note.

Technically, you can remove the token in the setting listed above, and the site should generate URLs with the queueID instead. This way you can work on clearing the tokens in the maestro_queue table and then running the updates.

You can also do something a bit more crafty, like

1. Copying the maestro_queue table to a new temporary table.
2. set the maestro_queue table token column to blank/null
3. perform drupal update
4. use sql to copy the tokens from the copied temporary queue table token column to the maestro_queue token column

Generally you'll only get that message when there is data in the column. However, you've noted that there isn't any data.

Before you do anything, always start by taking a full backup.

Then, on a non-production development system, try setting the maestro_queue token column to blanks and re-running the update.
Warning, this will update each row in the maestro_queue table:

UPDATE maestro_queue SET token=''

Then try running the update again. But again, only do this on a non production development system.

Merged the PR.

Thanks for the patch!

Check out this link

https://www.drupal.org/project/maestro/issues/3220629#comment-14144566 →

See if that helps you as it's a sample task console via views.

@Giuseppe87 for #89:

Drupal 10.1.6, VDE 8.x-1.4

Patch applies however, in my testing it would appear that the copy of the file never happens to the final specified location.

It seems the $options array has a key in [1], however it is blank.
$args, however, does seem to hold the path in separate array indexes.

I've attached an updated full patch here.

~line 920 of src/Plugin/view/display/DataExport.php, I've altered my version to look like

else {
      // Due to https://github.com/drush-ops/drush/issues/5009
      // we need to set the $context['message'] instead of $context['results'].
      if (in_array('vde_drush', $options)) {
        $file_location = implode('/' , $args);
        $vde_file = \Drupal::service('file_system')->realpath($context['sandbox']['vde_file']);
        // If set, copy the file to the specified directory.
        if (array_key_exists(1, $options) && isset($file_location)) {
          if (!copy($vde_file, $file_location)) {
            $error_message = t('Could not write to final file location (@file). Check permissions.', ['@file' => $file_location]);
            \Drupal::logger('views_data_export')->error($error_message);
          }
          else {
            $context['sandbox']['vde_file'] = $file_location;
          }
        }
        $message = dt('Data export saved to !download_url', ['!download_url' => $context['sandbox']['vde_file']]);
        $context['message'] = $message;
      }

      // We're finished processing, set progress bar to 100%.
      $context['finished'] = 1;
    }

#10 seems to only work for non-Layout Builder instances. Otherwise the callback_object in layout builder does not have a getEntity() method and fails.

_randy → created an issue.

Generally, we'd implement the Webform access rules and webform submission access api. It does feel "clunky" though rather than just a singular hook during submission access to modify.

Perhaps we just make this generic. We implement the access method in the MaestroWebformHandler which just does a hook invocation.

This way you can code up any sort of check and return value and we just pass that along as the return from the access method. We'd return Neutral as a default.

I just tweaked your patch to include the content wrapper that Claro uses to target that theme directly.
Needs review.

Bad form posting to a closed thread, however, there's been zero documentation that I can find that gives a really good example on how to use YAML Content module for importing a config page.

This is an example for those who come across this issue queue item.

I have a Config Page with a couple of Viewfield fields on it used as an admin page to show some live data. Pretty ubiquitous use of a config page.

Here's what I've done to make this work:

1. install the YAML Content module ( https://www.drupal.org/project/yaml_content → )

2. the custom module I have written has a /content folder within it.

3. I created the following yml file to populate a config page that has 2 viewfields on it. Named the yml file admin_dashboard.content.yml. The contents of the yml file is:

- entity: config_pages
  field_import_table_management: 
    - 
      target_id: admin_import_data
      display_id: block_1
      langcode: und
      delta: 0
      arguments: ''
      items_to_display: ''
  field_team_listing:
    - 
      target_id: admin_listing
      display_id: block_1 
      langcode: und
      delta: 0
      arguments: ''
      items_to_display: ''

I then import this via Drush like this:

drush yaml-content-import-module mymodule

where 'mymodule' is the custom module with the /content folder within it.

Hope this helps others so they're not fumbling around as I did for a few hours.

@mi-dave

Can you test this patch/update please? This should shrink the size of the field to 100 characters.

I've added a fix to Maestro to eliminate the warning for deprecation message.

You can either use the patch from the commit in this issue log or just use the DEV release until such time we have a new full release.

_randy → created an issue.

Commit for testing found here:

https://git.drupalcode.org/project/maestro/-/commit/983a04c8bea16eeb4919...

_randy → created an issue.

I've set it to use current(...)

Please test and set to reviewed if this resolves your issue.

I'd rather not use IN as this would suggest multiple IDs.

This should probably be more like

$query = \Drupal::entityTypeManager()->getStorage('maestro_production_assignments')->getQuery();
$query ->condition('process_variable', current($varID))
        ->accessCheck(FALSE)
        ->condition('by_variable', '1')
        ->condition('task_completed', '0');

Thouhts?

_randy → created an issue.

Dev release now has all updates to support this change for those who have not configured their handlers with the status selectors as well as for those using webform draft states that don't use custom Maestro handlers in place.

I had a stubbed out implementation of this handy, so able to quickly turn it around!

I have a second commit that fixed the type array issue already.

I'll take a look at the webform status, bit for now, this should probably do the trick.

Give the patch I just posted a try. Opens up a checkbox for a handful of options on webform submission statuses. This should help.

Fixed.

_randy → created an issue.

Zero user info

Maestro engine module config image added.

Heading alteration

Sitewide token API usage

Provided new hook to allow for altering of "internal" URLs to pass the sitewide token.

_randy → created an issue.

Starting sitewide token

Sitewide token and zero user notification

Sitewide token information.

Sitewide token information added

Remove "8" as reference for Drupal in the 3.x branch

Pushed to DEV branch and need review prior to going into release.

Committed to DEV branch for final test before release.

_randy → created an issue.

_randy → created an issue.

This is happening in Drupal 10.1.1 as well.
After syncing an entire site's config to the target site, I have 106 config files that import just fine, but remain in the Config Sync UI. Only differences are the ordering of the config parameters.

Manual import via Devel config editor does not resolve the issue and nor does a manual import via the Single Config import option.

Agreed with everyone on this thread asking to reopen. This is not resolved.

I currently have 106 config YML files that successfully import, yet they do not disappear from the sync page once imported. The differences between the current and staged configs are ordering of the config parameters within the staged file compared to that of the in-system configs.

Updating the issue to the 3.1.22 version.

I also see this issue.

I am denied access to a node by going directly to the node view page.
However, I can create a block view and show the restricted node in a block on the node view page!

I can also see the restricted node show up in search results, but access is denied when clicking on the search result.

This is a pretty major issue.

_randy → created an issue.

@benjaminarthurt

Can we roll these patches and the D10 support patches into a release?

_randy → created an issue.

I can concur on D10.0.3, patching ECK to use || 10 does indeed work at the moment.
Please commit to dev branch at the very least.