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.
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.
Specifically in my case, it's the following that is the issue:
$vars['rows'][$id]['attributes'] = new Attribute();
if ($row_class = $view->style_plugin->getRowClass($id)) {
$vars['rows'][$id]['attributes']->addClass($row_class);
}
$vars['rows'][$id]['attributes']->addClass($col_classes);
}
If I comment out the $vars['rows'][$id]['attributes'] = new Attribute(); and the $vars['rows'][$id]['attributes']->addClass($col_classes); lines, it works just fine.
I haven't had a chance to dig further why it's the row attributes. The only thing I can think of right now is that we're not using fields? We're using display modes on rendered entities. Not sure.
I also added translation to the top menu item title attribute.
@shelane
The data in the view is two content types (just regular old nodes).
Configured to show rendered entity content, not fields, using a specific display mode.
Format: Bootstrap Grid - Settings were straight out of the box - no changes.
As noted, this worked fine prior to the Beta and RC releases.
Issue is in template_preprocess_views_bootstrap_grid function in views_bootstrap.theme.inc file.
In the alpha version only $vars['row_attributes'] was set to "new Attribute()".
In the latest versions, $vars['attributes'] is set to "new Attribute(['class' => 'grid']);"
This creates the issue with Drupal core.
@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
- Copying the maestro_queue table to a new temporary table.
- set the maestro_queue table token column to blank/null
- perform drupal update
- 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.
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.
Commit for testing found here:
https://git.drupalcode.org/project/maestro/-/commit/983a04c8bea16eeb4919...
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?
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.
Provided new hook to allow for altering of "internal" URLs to pass the sitewide token.