Sub-Parameter enhancement

[P3AdminAccount]

Summary

Sub Parameters in the Plugin definition

I love the flexibility of feeding parameters to the job scripts. We have kinda gone overboard on using them. One plugin we created has twenty parameters. This brings us to the question, would it be possible to group parameters with sub-parameters. This means you have a primary parameter (maybe a checkbox) that checkbox is associated with sub-parameters which can be checkboxes, menus, text boxes, or text areas, and be able to nest even further down under.

[jhuckaby]

Hey Mark! I'm so glad you are using the plugin parameter system so heavily!

That's a great idea. It might be difficult to retrofit this onto Cronicle v1, which is in maintenance mode, but I will absolutely take a look at it for v2.

Building a UI "editor" for these things is always tricky, when you get into groups and nesting. It almost seems like a JSON file would actually work better, on the admin side I mean (for creating the plugin parameter "definitions"). Would you be into that? (You would edit the JSON right in the UI of course). Something like this:

[
	{
		"type": "select",
		"id": "method",
		"title": "Method",
		"value": "GET, HEAD, POST"
	},
	{
		"type": "text",
		"id": "url",
		"title": "URL",
		"value": "http://"
	},
	{
		"type": "textarea",
		"id": "headers",
		"title": "Request Headers",
		"value": "User-Agent: Orchestra/1.0"
	},
	{
		"type": "textarea",
		"id": "data",
		"title": "POST Data",
		"value": ""
	},
	{
		"type": "section",
		"title": "Advanced",
		"state": "closed",
		"contents": [
			{
				"type": "text",
				"id": "timeout",
				"title": "Timeout (Seconds)",
				"value": "30"
			},
			{
				"type": "text",
				"id": "success_match",
				"title": "Success Match",
				"value": ""
			},
			{
				"type": "text",
				"id": "error_match",
				"title": "Error Match",
				"value": ""
			},
			{
				"type": "checkbox",
				"id": "follow",
				"title": "Follow Redirects",
				"value": false
			},
			{
				"type": "checkbox",
				"id": "ssl_cert_bypass",
				"title": "SSL Cert Bypass",
				"value": false
			}
		]
	}
]

Notice the section which has nested controls inside it, which also has a state that starts closed, but can be toggled (hide / show). These sections could go inside each other, any number of levels deep.

And then that JSON would produce a pleasant, nested UI for your users on the event / job side for configuring events and running jobs.

So the only time you ever need to edit raw JSON is when you are defining or updating the Plugin Parameters themselves (admin work).

Thoughts on this?

[P3AdminAccount]

Perfect. That proposed approach would be much faster for setting up the twenty-plus parameters we had to put in manually. Making UI to make UI is time-consuming and the audience for this plugin is very comfortable with JSON editing.

Also, when do you plan to release version 2? I assume you will have an upgrade tool for migration.

One other item that you may have dealt with in the upcoming version. When you edit an event, change parameter(s), and use 'Run Now' it saves those parameters. That can be a scary situation. For example, we are running an event that imports data using a menu parameter with the values of Standard and Override. Standard does data integrity checks but if there are errors, it halts the import job and alerts us by email.

Override ignores the data check and imports the data. Normally the event is scheduled using the Standard parameter and performs the data check. Sometimes we get a call from the data stakeholders and they ask us to override the checks to force an update to the data. So then we edit the event to run it manually with the Override parameter. Since you are saving the current parameter state with the 'Run Now' and if we don't remember to switch the parameter back to Standard and save it, the scheduled event runs with the Override parameter set. It is such a worry, that we have created two events, a Standard scheduled one and an Override one on demand.

[jhuckaby]

Got it, thanks!

Yeah, v2 does away with the "feature" that temporarily saves the current event "edit state" in localStorage (browser), and restores it when you come back to the page. It was a stupid idea that should have never been released.

v2 is scheduled for release sometime in 2024, but OMG life keeps getting in the way 😊

How could it be the end of April already??? GAH!

[jhuckaby]

I've also disabled that awful feature in Cronicle v0.9.47, which just dropped.