BackgroundTask's "Run now" action does not respond

[Xteuk]

Hello,

Since I've updated to last version (from a very old one), I'm unable to make the "Run now" action to work. I've created the simplest VAF to try this, and I've tried plenty arguments of "TaskQueueBackgroundOperation.DashBoardRunCommand". The link is visible in the Dashboard, its text can be changed, but still nothing's triggered.

It's still possible I'm using it incorrectly, of course. Can you help, please ?

On StartApplication() :

On OnConfigurationUpdated()

MFiles.Fealinx.TestVAF.zip

[CraigHawker]

The TaskBackgroundOperationManager was designed as a "sticking plaster" over the old background operations. We would recommend migrating to the attribute-based approach instead: https://github.com/M-Files/VAF.Extensions.Community/tree/master/MFiles.VAF.Extensions#using-vaf-23-task-processors

However: I guess this should work. My assumption is that the command isn't being correctly registered, thus the button is shown but it doesn't get wired up to anything when it's rendered.

[CraigHawker]

I just debugged the code and it appears that there is some issue returning the commands for the background operations manager. For now I suggest two alternates:

1. Migrate to the new approach (recommended)
2. Alter your code as below

// In VaultApplication.cs:
public override IEnumerable<CustomDomainCommand> GetCommands(IConfigurationRequestContext context)
{
    var commands = base.GetCommands(context).ToList();
    if(!commands.Contains(this.SyncBackgroundOperation.DashboardRunCommand))
        commands.Add(this.SyncBackgroundOperation.DashboardRunCommand); // Add your command.
    return commands;
}

[Xteuk]

Thank you so much for this quick answer. Tested and confirmed. I'll implement a fix for our customer right now. There's some Attributes I wasn't aware of (like [ShowOnDashboard]), so thank you also for this documentation page.

The customer's VAF is configurable, so hard-coding the attribute is not my best choice, but i'll prefer that on other implementations (and maybe next evolution of this one)

[CraigHawker]

I'm going to re-open this as I am going to take a quick look to see whether I can resolve this now. It's definitely a bug.

To your other point though: In general the task processor approach should be able to be just as configurable as the other one, but the infrastructure is so much easier to get going with. You may, yes, end up with a smaller number of queues and task types (because those have to be compile-time-constants with the attribute approach), but that's not necessarily a practical constraint.

[CraigHawker]

Should be resolved in version 24.10.72, currently being pushed to nuget.org.