thieman
Job Categorization
Related to #62. The ability to categorize jobs could make things a lot more manageable if you have a bunch of jobs in the system. Additionally, this should serve as the top level of configuration rather than having global defaults in the config.
Job-level configuration would override category-level configuration if set.
New jobs should be placed in a default category that is configurable just like user-created categories are.
Anything we can move out of the config file and into backend-managed state (and the UI) is a win for usability, too.
Here's some ideas, stolen from my experiments using rundeck:
- Add a category attribute/column to a job (now each job has a "category" which could be reflected in the UI)
- Categories may adhere to a path-based convention, ie "ETL/scrapers" vs "ETL/ftp_data" vs "server_maintenance" vs "server_maintenance/deployment" etc.
- This way the front end can easily interpret the path and handle any sort of nesting of categories, with a folder-like convention
This could be a 2 step approach, with the base case of a single category being pretty simple (add a column, relect in UI), and a good step towards organization. The second step, if desired, would involve handling path-based categories allowing for more hierarchical organization.
I'm not necessarily married to hierarchical organization other than simple one-level categories, but it would provide the most flexibility/organization in the long run. Down side is UI complexity. My thought is if we do not implement it, we should design the implementation for single-level categories with the thought that it may in the future be extended to implement hierarchical categories.
Other consideration for hierarchical organization is whether path-based hierarchy makes most sense (ie string paths and having UI handle it) as opposed to having it be in the back end. When considering configurations on the hierarchy level, using string paths could be limiting, but implementation or hierarchies in back ends would add a lot of complexity (see this for ideas).
My instinct is to ship simple categorization first and then upgrade to hierarchies if we think they're necessary. I agree with you that hierarchies add a lot of complexity to the UI and the SQL backend, so let's not bother with them unless we need to.