Updates to modules showing in repo but not modules toolbox

I think what might help would be to know how to construct filters in the module toolbox that help classify the modules according to the level of attention required. In my case these classifications also map to:

• Up to date - no attention required
• New - cursory attention required (ability to back out needed)
• Updated Not in Use - cursory attention required (ability to back out needed)
• Updated In Use - that hasn’t been customized by me, moderate attention required
• Updated In Use - that has been customized by me, heavy attention required

I currently tell the difference between the last two using some custom software I’ve built that parses out and identifies the differences between the repo and the currently installed modules. It also displays the update history, which easily identifies a module that has been customized vs. updated from repo. @Michael Rodrigues, I know you and i have talked about the ability for the toolbox to track this not just on a module level, but on an attribute level. That should help.

Here’s my workflow. If this workflow breaks, i can either build a new workflow or abandon doing the work. 

1. New
   1. make a note of the date/time (my script preps this list so i can bulk copy/paste into my changelog system)
   2. pull them in
2. Updated not in use
   1. make a note of the date/time and the old version of the DS in JSON (so i can roll back if needed) (my script preps this list so i can bulk copy/paste into my changelog system)
   2. pull them in
3. Updated In use - not customized:
   1. make a note of the date/time and the old version of the DS in JSON (so i can roll back if needed)
   2. check if any changes would cause instances to disappear, new alerts to open, or customizations to be overwritten (decide go/no-go)
   3. pull them in
4. Updated in use - customized:
   1. make a note of the date/time and the old version of the DS in JSON (so i can roll back if needed)
   2. check if any changes would cause instances to disappear, new alerts to open, or customizations to be overwritten (decide go/no-go)
   3. pull into sandbox. Copy script(s) to DS editor in prod and test extensively (decide go/no-go)
   4. copy changes from sandbox to prod without overriding prod customizations (most often not fields yet preservable in module toolbox sadly)
   5. mark prod DS as audited so it no longer shows up as having an update

Elsewhere here we’ve asked for the ability to download tables in CSV format. Keeping my change log up to date is easy today because my script fetches all the data from the api and formats it in a way that’s easy for me to pull into my changelog. I can’t do that once the functionality is only available in the module toolbox. Having the ability to download the table from the module toolbox would alleviate that issue, especially if i can figure out the filters to replicate the four classifications above.

If a new interface is being designed and it makes a workflow harder or impossible, what’s the point of the update? I get that ease of manufacture is a goal of UIv4, but that can’t be at the expense of usability. Otherwise you’re making an upgrade that costs the customer without providing a corresponding value.