Delete multiple IEDs

[danyill]

Is your feature request related to a problem? Please describe.

Sometimes I really want to delete multiple IEDs. Doing this one by one I find a little tedious which is the only option we currently have in OpenSCD.

Describe the solution you'd like

I thought about having a menu plugin to do this but I worry about the clutter of many menu plugins. I think the solution I would like would be a filtered list of IEDs accessible from the IED editor.

Perhaps something like this:

Similar to the selecting of a single IED but with checkboxes.

Requirements

Ability to multi-select IEDs. Ability to filter by manufacturer, type and name.

This could be a separate component or part of oscd-filter-button which we already have some functionality for in the IED editor.

Suggestions for a specific user interaction

I suggest a button which opens up a dialog with a filtered list.

[microjacobon]

We could also add a delete button on hover into the select IED, as this is the place where you need go anyway if you want to edit or delete some IEDs. It would probably be more effort, but it could look like this:

[danyill]

Thanks - we could do something like that but it would only be slightly better. The user still becomes the "sorting, filtering and multi-select clicker".

Ideally, I would like to bring the full power of the filtered list to this functionality:

• filter and then select all
• filter on name, manufacturer and IED type.
• filter on IED description

I think the idea we proposed during refinement of having a "Manage IEDs" editor to include functionality including:

• Delete IEDs
• Import IEDs
• Import Template IEDs

might be a way forward for "bulk operations".

I think the need is "mostly" self-evident but since needs rarely are, I can imagine:

• Needing to rebuild templates for particular device or device type because an error in a typical or template file is found
• Needing to rebuild templates for a firmware or device model update

One particular use case I have in mind is that we are still decide if we manage our Protection 1 and Protection 2 system as two scd files or one. The reasons for managing it as two systems mostly come down to minimising risk of configuration errors impacting both systems (which would be more manageable if we had comprehensive diff-ing functionality). Otherwise, managing it as one system would be easier.

If the answer is two, we will frequently be having to merge and then separate where the systems must communicate with each other (or creating sed exports or similar if that is even a good idea) which will look like:

1. Initial Prot1 and Prot2 system in separate files
2. Combining files where required to configure GOOSE (mostly line protection autoreclose and block)
3. Temporary "saves" of the combined system for loading into ICT tools for line protection.
4. Separation out through deleting the Prot1 or Prot2 IEDs.

[github-actions[bot]]

Hello there,

Thank you for opening this issue! We appreciate your interest in our project. However, it seems that this issue hasn't had any activity for a while. To ensure that our issue tracker remains organized and efficient, we occasionally review and address stale issues.

If you believe this issue is still relevant and requires attention, please provide any additional context, updates, or details that might help us understand the problem better. Feel free to continue the conversation here.

If the issue is no longer relevant, you can simply close it. If you're uncertain, you can always reopen it later.

Remember, our project thrives on community contributions, and your input matters. We're here to collaborate and improve. Thank you for being part of this journey!

[danyill]

Dear Bot,

Alas, still relevant and requires attention.

Love and Hugs,

Dan

[github-actions[bot]]

Hello there,

Thank you for opening this issue! We appreciate your interest in our project. However, it seems that this issue hasn't had any activity for a while. To ensure that our issue tracker remains organized and efficient, we occasionally review and address stale issues.

If you believe this issue is still relevant and requires attention, please provide any additional context, updates, or details that might help us understand the problem better. Feel free to continue the conversation here.

If the issue is no longer relevant, you can simply close it. If you're uncertain, you can always reopen it later.

Remember, our project thrives on community contributions, and your input matters. We're here to collaborate and improve. Thank you for being part of this journey!