I've read through the kb article, that part of JD2 is understandable. Now that I had some time to think about the whole thing, I see that I need to split the initial post in two specific parts.
"Grouping" and as the linked ticket implies, custom *default download directory*.
"Custom *default download directory*" I think is rather easy to understand as wanting to use the packegizer rules, while defining a custom location.
And "Grouping" is a tricky one, which depends on how you look at it.
When you have multiple links that are manually(|api|crawljob) entered into the "Add Link" dialog, one might want to have the downloads grouped based on the "Package Name", but still retain the folder structures.
Say you get three links with familiy photos and videos fromwomandad and aunt. You would not want to mix all the files in the same folder, so you would want to have the "Subfolder by (org)packagename" and/or "Adopt folder structure" to apply to all three links.
Also, when you add the links, you want to have these "subfolders" and "folder structures" to be grouped in dedicated folder "Family_20221206".
So, in a(my) perfect world you would have a workflow where:
- "Information overwrites packagizer rules" is disabled
- Multiple Download Links are inserted
- A package name is defined ("Family_20221206") and "Group by package name" check box is set
Which would result in:
- Default download path used
- Folder based on the package name from "Add Links" is created
- The structure of the links is applied
- All Packages would be named using the "package name" from "Add Links"
Resulting in something like:
/output/Family_20221206/<jd:subfolderbyplugin>(link 1)
/output/Family_20221206/<jd:subfolderbyplugin>(link 1, subfolder 1)
/output/Family_20221206/<jd:subfolderbyplugin>(link 1, subfolder 2)
/output/Family_20221206/<jd:subfolderbyplugin>(link 2)
/output/Family_20221206/<jd:subfolderbyplugin>(link 3)
And the cherry on top would be to have the package name from "Add Links", be applied to all "packages" that would be created: See
This has more to do with programmatically adding and checking the state of links and downloads. Ontop of that, having a human be able too look at the running process.
On one side the human would be able to search package name "Family_20221206" and find all related entries that are (being) downloaded.
And on the other, to query packages via api and see their state programmatically.
(This might be my ignorance) If the Packagizer had the ability to access values from "Add Links", then maybe the whole thing might be easier to be done in the packagizer rules?
Like, if you have access to "Download Path", "Package Name" and whatever there is from "Add Links".
You might go and say:
- Use "Add Links":"Download Path" (which is set to default download path automatically) as "Download Directory"
- Append "Add Links":"Package Name" to "Download Directory" if "Add Links":"Package Name" was set
- Use Default "Adopt folder structure" rule
- Force all package names to be "Add Links":"Package Name" if "Add Links":"Package Name" was set
And now the whole headache of "Information overwrites packagizer rules", rule not applying and what not would actually be less of a problem at all.
Because by default, the system would use the Packagizer rules as is. And if someone sets "Information overwrites packagizer rules", then the the things can work as they have worked all the time.
So to say, there would be real change from how current setups run.