-
-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Job Categorization #21
Comments
Here's some ideas, stolen from my experiments using rundeck:
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. |
+1 to that |
Friday May 09, 2014 at 02:01 GMT
Originally opened as thieman#63
Related to thieman#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.
The text was updated successfully, but these errors were encountered: