ScheduledTask: TaskPath should be a key property

[bozho]

Details of the scenario you tried and the problem that is occurring

We're in the process of moving scheduled tasks to a different path and we'd like to keep the names.

However, creating two ScheduledTask resources (one to create a new scheduled task, the other one to remove old ones in the root) causes a conflict, since only TaskName property is the key property.

Verbose logs showing the problem

Suggested solution to the issue

Mark TaskPath property as a key property.

The DSC configuration that is used to reproduce the issue (as detailed as possible)

ScheduledTask "new_task" {
    TaskName = "task_name"
    TaskPath = "\NewPath"
    Ensure = "Present"
    ...
}

ScheduledTask "old_task" {
    TaskName = "task_name"
    TaskPath = "\"
    Ensure = "Absent"
    ...
}

Happy to submit a patch.

The operating system the target node is running

Version and build of PowerShell the target node is running

Version of the DSC module that was used ('dev' if using current dev branch)

6.5.0.0

[bozho]

Oh, I see the problem. If I mark a property as a Key, the corresponding parameter has to be Mandatory, which means it has to be specified when creating a resource instance.

[PlagueHO]

Hi @bozho - I think this is worth considering. It would result in a breaking change but may be something the community would be ok with to gain the functionality you describe.

It also would allow jobs with the same name to be created in different folders.

Let's open this up for community discussion and also bring it up at the next community call..

[bozho]

Ok, sounds like a plan.

An easy win here would be to allow TaskName to be given as path\to\task\MyTask, which would then be parsed for the path and task name, as task names cannot contain \.

[PlagueHO]

So the options would be:

1. Leave as is.
2. Remove TaskPath parameter and combine with TaskName.
3. Remove default from TaskPath and make a key.

Options 2 and 3 would both be breaking change.

I tend to like Option 3 if we're going to be making a breaking change. @johlju ?

[bozho]

I like No. 3, too.

[johlju]

I actually like option 2. It allows using the same task name in different folders and for those that don’t care of path can just specify the name of the task and the resource defaults to root (for TaskPath). Going with option 3 a consumer must always specify path even if they don’t care because the want it to be in the root path. I feel that adds unnecessary configuration for something that should be optional.

Going with option 2 the path is still optional, but still can be used to control where the task should end up.

With option 2 we could keep the TaskPath parameter as is. If specified it will override any path in the TaskName parameter. That would keep existing configurations to still work, meaning it would not be a breaking change going with option 2.

[johlju]

Updated previous comment. Commenting from my phone is not the best experience :)

[johlju]

Hmm... keeping TaskPath as suggested above could potentially break in a certain scenario. When using a TaskName with different paths but the same TaskName, and TaskPath is set to the same path. In that scenario it will create two task with the same name in the same path which would fail.
Maybe if we opt to keep TaskPath it could override the path, but write out a deprecation warning. Then we can remove that deprecation when we have more breaking changes.

Still like option 2 better (with or without keeping TaskPath)