Forum Discussion

Anonymous's avatar
Anonymous
2 years ago

Updates to modules showing in repo but not modules toolbox

Why would this be? There were 5 updates to aws_billing_* modules today, but they only show up when i use the traditional repo update option. No combination of filters could show those in the module toolbox, except by clearing all filters and just searching by name. Even then, once found by name, they showed already up to date. 

In addition, when trying to make a filter to show them, i was frustrated (once again) that the filters are filtering by values we cannot see:

  • The “Customized” field isn’t displayable on the table at all, or if it is, it’s displayed as an icon in the status column. However, the dropdown for the filter is not an icon, it’s text. 
  • The status column shows an icon, but the filter values are text. Which icon corresponds to which text? 
  • For these 5 modules, the “Support” column was blank, even though these modules come from LM so should be “official”? How can you filter by “Support” == null?

It’s all very Duolingo: make mistakes and wander your way through until you figure it out?

  • Anonymous's avatar
    Anonymous

    Ok, I gave it a college try today. I set my filter to:

    • Skipped = “Show only skipped” (don’t get me started on why this isn’t the same kind of dropdown as “customized”)
    • Status = “Outdated”

    This seemed to get me the list of modules that i have audited in the repo. There were a couple that showed updates, so i checked them out and they were innocuous so i applied the update. Guess what shows up in the repo as now having an update? The ones I updated through the toolbox. So, the source code for the toolbox and the source code for the repo are different.

    How are we supposed to transition to the new system if using the new system throws alerts in the old system (which we’re still using)?

  • Anonymous's avatar
    Anonymous

    At the least, can you guys let us know when you plan to mark as skipped everything that is currently audited? That would let us know when we should stop auditing and start skipping. As mentioned before, I have 73 audited modules;  marking each one as skipped manually would be a big time suck.

    Also, when that expected time comes, hopefully it can be more accurate than the “your portal will be upgraded to v.NNN on Monday” message;  it’s almost never right, it might be Monday or Tuesday or the next Saturday before it’s upgraded.

  • Anonymous's avatar
    Anonymous

    If it can be migrated, can it be automated so that i can continue with my current processes until the toolbox is a bit more workable?

  • @Stuart Weenig we’re planning on disabling the old Audit system and migrating those audits to the Skip system in Toolbox. We had previously migrated Audits but we failed to disable it afterwards.

    Audit and Skip solve the same use case of hiding updates you’re not interested in.

    I suggest using Skip in the Toolbox and not using Audit in UIv3, though again, it will be migrated.

  • Anonymous's avatar
    Anonymous

    It turns out (based on some conversations with @Michael Rodrigues that Auditing a datasource through the old method is a completely different and totally separate action from “skipping” an update in the module toolbox. Meaning that all 73 of our audited datasources will eventually have to be skipped in the module toolbox.

    I just hope they don’t remove functionality that we’re using until the replacement is usable. To be clear, I believe the module toolbox is not usable currently.

  • We reported similar results to our CSM a month or so ago. We were asked why we refuse to use the newer system and we brought forth the reported difference between the two.

    We also see datasources marked for update that aren’t customized and are up to date at times in the newer system.

    Also our lack of confidence in the newer method as, at least in prior years, wouldn’t actually preserve the customizations made.