scheduled tasks

It's a free text field. There is no dedicated logic.

few things I've used before:

Can just be a char-delimited string. e.g. pipe | : "path=xyz|debugmode=false"

string split it in code; could even map it to a custom settings object.

When adding more complexity you could also add a json-string and use a lib to parse that to a custom settings object. Downside is that the editing of the json object might be harder for non-techs.

https://stackoverflow.com/questions/9988395/how-to-map-json-to-c-sharp-objects

You could also just create a custom settings block for this import. This way you could use the default controls for path selection, drop down lists... etc. pro of this approach is that you can add specific validation and can be sure the settings are there.

https://docs.kentico.com/k12/custom-development/creating-custom-modules/adding-custom-website-settings

what ever approach you use make sure to add enough validation in code and don't make any assumptions on values or settings being present. Either cancel the task with an error message or make sure to add default values.

Many Thanks, some ammunition to play with ....

I like the settings block solution. Basically i create my module block, values can then be set and called from my Scheduled Task, code behind, seems a lot cleaner solution as well.

Correct, basically the only downside is that you get a relation to two lose objects. So it's possible to setup the task and forget or remove the settings.

That's why I mentioned about being extra defensive in code.

On top of what David mentions, we've also used custom table records with specific "key values" to specify grouping of objects we want to run. For instance, find all custom table records in table1 where grouping = "group1", then execute your scheduled task for each record found with the custom data attributes in each row.

Quick question, i have set up the module to pass parameters to my task scheduler code behind. I was trying to use basic SQL syntax to populate my dropdown such as : Select CMS_Document.DocumentNamePath From CMS_Document , but doesn't like it is their some form of variation in sql syntax in kentico ?

Typically to populate a dropdown, you need 2 fields:

• name
• value

So it should read:

SELECT DocumentNamePath, DocumentNamePath
FROM CMS_Document
ORDER BY DocumentName

Thats ok i figured it

Brenden could you please elaborate more on your explanation on what i am trying to achieve.

One example I have is a scheduled task which processes specific tables records for cleanup for data privacy. The table has the following columns:

• ScheduledTaskClassName
• ClassName
• DaysToGoBack

In my scheduled task, I do a lookup of all the records in that given table based on the Scheduled Task currently executing and the ScheduledTaskClassName in the records of the custom table. When I get those records, I then do a look-up of the data info object based on the ClassName field and execute a "DELETE" statement of the records from the given object.

The same can work with what you're explaining but it doesn't require you to add another setting to a group of settings. It will only look for the given records in the database vs. a parent/child lookup. It also allows an advanced content editor to manage.

finally, I have been looking at options for presenting the user the ability to group pages into specific categories. I have performed a test on the corporate site using the DocumentNamePath, what is unusual i expected just the paths i see in the content tree, but i am getting hundreds of returns which aren't visible in the content tree list. why would that be. Is the DocumentNamePath a bad choice for grouping ?

Regarding grouping, DocumentNamePath is not a unique value, especially if you have multiple languages in your site. For instance you could have

/about/contact in en-US
/about/contact in fr-FR
/about/contact in en-GB

So not really a way to be grouping unless you're checking the culture specifically.

Thank you both for your input, gives me something to think about. My biggest problem is thinking about some logic for actually associating pages with categories. As i explained to my manager, you need some form of commonality in order to generate some form of consistent logic. Still trying to come up with a game plan. With over 2,000 pages, not the easiest of tasks.

Back to the DocumentNamePath, would it be worth pursuing if I filtered on culture ?, I am also assuming their may be duplicates in the workflow as well. As discussed just trying to come up with a less than arduous way of grouping these pages

I'd use the out of the box categories vs build something. DocumentNamePath isn't a unique value. Not only for the reason I already mentioned but if you have multiple sites you need to look at the site id too (and most likely a few other things)

Ok, Thank you for your input. I feel a lot of the issues was in the initial designers not thinking about grouping pages initially into some form of structure. Again thank you.