@SamFritz @ianmilligan1 I've spent a few days on implementing this, but there are a number of gotcha's with the implementation.

• Right now we use sorttable.js along with some custom keys which allow us to sort out tables. The current implementation doesn't allow our tables to be paginated.
• Implementing wicegrid, we gain some "nicer" styling, but don't gain much else because of the way we display data on the jobs table. Much of that data is displayed via helper methods, which according to my research can't be sorted our filtered via wicegrid. For example, on the jobs table, the collection name column can only be searched/filtered via the collection id. Since there are potentially a couple thousand collection ids, this really isn't ideal. Same goes for institution and user.

The ideal way to implement it would be to store the actual values in the dashboard table. We'd need to setup a db migration, and migrate all the existing data (not fun, but doable), then actually implement wicegrid. So, the big question is do we actually want to take the time to do this? Or, is the current jobs dashboard sufficient?

Oh, and the datepicker and jquery-ui functionality in wicegird is janky to say the least. Setting it up broke the table UI, and littered the console with a bunch of jquery-ui errors 😭

Based on the above, my gut inclination is to say that the current jobs dashboard is sufficient (more than sufficient, IMO) and I would recommend shelving this for now. But I am happy to defer to you @ruebot or others too.

Thanks @ruebot for outlining the pros/cons! I would agree with @ianmilligan1 comments.

Reviewing current capabilities of the jobs dashboard (and the others), I think it's set up quite efficiently for how we are currently interacting with the data (easy to use, clean, and when we are looking for specific info on a job we can find it with relative ease). So I think shelving wicegird makes sense.

Thanks y'all!

I'll mark this as closed/won't fix.