nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Ability to Remove Asset Types, Change Terminal Configurations, Etc.

JCGuarneri

After using the Utility Network for a few years, we have a number of asset types that are either no longer needed or we discovered require a different terminal configuration than what was originally set up. It would be really beneficial to be able to modify or delete subtypes and their terminal configurations to meet changing needs.

I understand this must be a difficult feature to implement without risking breaking UN functionality if used carelessly. But I think this is essential configurability functionality.

Trouver plus de publications taguées avec

Status: Ouvrir

Réponses

GIS_kiwi4

I can see the benefit in being bale to change things on the fly - remove asset_types, change terminals, etc. But I don't believe we will get this as I agree with your statement. This can be a nightmare to manage without breaking things, specially if you leave it to the users.

Maybe there could a "modification" wizard where you are handheld through the process.

But for now, we will just have to stick to the export to asset package -> Modify -> Apply Asset Package.

ThatGuyOverThere

Can you not just go through and modify the rules, terminal tables, and remove all of the subtypes you're referring to by hand?

JCGuarneri

@ThatGuyOverThere The schema is additive only. So while you can remove all the connectivity rules, you can't remove a subtype or asset type. Or even rename them. Editors can add the features or change to an "invalid" asset type, and break connectivity. And once you've set a terminal configuration on an asset type, you're stuck with that terminal configuration. Theoretically, you should know ahead of time what the right one is, but we've encountered a couple instances where we realized we had it wrong the first time.

There's probably a way you could do it in SQL if need be, but I'm pretty sure that would void the warranty.

Rejoindre la conversation

Connectez-vous pour publier, suivre du contenu, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.