Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Seeking community feedback on SQL Agent UX prototype #750
referenced this issue
Feb 21, 2018
I think it has a nice clean look. A couple comments, all of which of course would need to be borne out with more feedback:
I got a little lost at the point where you said, install the extension then also add it to the dashboard. I understand the idea of having to install the extension but once installed it should be available to all servers.
In the jobs list, need an indicator for disabled jobs.
Overall, great job on the UI.
Need support for job categories, the ability to create and recall filters and columns in the job list and the ability to script out the job definition to tsql. It would also be nice if you could add support for starting a job at a given step. It also looks like there is no support for setting up on fail and on success steps
A good beginning, but I agree with @Code-DJ I shouldn't have to both install and add the extension for use.
It's not clear when you initially edit the job step to make sure the job runs, that it is only for that run. My assumption would have been that I am editing the actual job step.
Requirements for the advanced tab would be to see where the log file is being output to.
The job view shows the target server, but it actually is displaying the schedule.
Is the Error message the same as what we would currently see in the Message field when looking at the job history in the log viewer or msdb..sysjobhistory? Assuming it is, is the field displayed being limited to a certain number of characters or is it collapsible? Having 4000 characters of output message shoved right under a "failed" status, but above the other info pertaining to the job run will be unwieldy (and annoying) without a way to control it.
Additionally, for those of us with large output going to a table or file, the standard Message won't necessarily contain the actual point of failure. It probably shouldn't specifically be called "Error message" on the dashboard unless you've got some way of presenting just the actual error message.
Also, having an option to pull the full log from the table or get the filepath to the output file would be nice.