You won’t see modules you don’t have in the Toolbox, so the Exchange is the only place to see new (uninstalled) modules.
TIL. I never really understood why there should be a separate toolbox from the exchange. Would rather have one searchable/filterable list to rule them all. Even your own filtering options for the same kind of thing have different names depending on whether you’re in the exchange or the toolbox. I have not been on the exchange page in over a year. Do you have usage stats on it? Do people actually use it? Why does the exchange even list the installed modules?
You may want to supplement these by looking only at Official modules, but if you have Community modules and those have updates, they’re probably worth looking at too.
Community stuff cannot be trusted to receive updates, so I never use it. The exception is if there’s a github repo that i can follow.
Currently, there is no way to differentiate in use from not in use, or to see which side customizations were made on (you vs us) with in the diff. We do have all this data though. 195 will see the rollout of the “In Use / Not in Use” column for some modules types, and it’s more advanced than the old school AppliesTo check that Import from Repository uses (and which you technically can tediously recreate by testing AppliesTo on each module). There will be a filter for this as well (and you can sort by how in use it is).
Is that going to happen simultaneous to losing the audit module functionality? What will the in use/not in use be based on? Actual instance counts? Could we just get the instance counts and resource counts in columns? Is the ability to run an adhoc “test appliesto” and/or “test discovery” still on the roadmap?
You can see “Customized” status today to know that you customized a given module from our defaults, but again, that doesn’t extend to the field by field diff (though we have that info and hope to show it in the UI).
This will help immensely with the actual heavy lifting of merging in updates. Currently I just look at the diffs in my tool (which diffs all fields not just preservable ones and decodes the code and diffs line by line). Understanding the decisions the ME team makes without any context can sometimes be difficult.
It’s going to be difficult for my team to allow access to thew new APIs (we don’t control API access, but we do build the LMX APIs), but if you’re cool with something like a CSV export, I’m pretty confident we’ll be able to create something you can use to get back to a similar (if not better) flow.
Obviously today, I built my own module toolbox to help me analyze the diffs. Having a CSV/JSON endpoint i can hit in a script will allow me to still update my changelog. Once all this mess is actually working, I’d love to talk about enhancing the change log so i don’t have to maintain my own.
Last week (in the context of the API difficulties), one of the BE engineers actually recommended just providing a simple export for power users who wanted the info but didn’t want to deal with our tooling/ui/flow.
Yes, that would help ease the transition until the kinks are worked out of the module toolbox workflow.
