Forum Discussion
Here’s how those filters map to those conditions (just click Clear and enter the relevant filters for Toolbox or Exchange):
- Up to Date
- Toolbox
- Status: Up to Date
- Exchange
- Installed & Up-to-Date
- Toolbox
- New
- Toolbox
- You won’t see modules you don’t have in the Toolbox, so the Exchange is the only place to see new (uninstalled) modules.
- Exchange
- Status: Not Installed
- Toolbox
- Updated
- Toolbox
- Status: Outdated
- Exchange
- Status: Installed & Update Available
- Status: Installed & Update Available
- Toolbox
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.
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).
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).
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.
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.
Related Content
- 3 months ago
- 11 months ago
- 7 months agoAnonymous