This pull request has been mentioned on Pi-hole Userspace. There might be relevant details there:

https://discourse.pi-hole.net/t/deleting-a-group-is-not-possible-ftl-v6-0-4/77171/9

Ah, nice. So deleting a group just deletes the group assignment. Is there a feature that can list domains that are not assigned to any group to give users a quick way to replicate v5 behavior and know any orphan domains that are able to be culled?

Is there a feature that can list domains that are not assigned to any group to give users a quick way to replicate v5 behavior and know any orphan domains that are able to be culled?

One can abuse the sorting function of the table.

I understand your point of view, but some users will assign hundreds of domains/regex and list to a group and when they want to delete the group they will need to manually remove every assignment, one by one.

I think the users already knows how v5 works (and we never received complaints).

In my opinion, replicating v5 behavior won't cause any issues.

In my opinion, replicating v5 behavior won't cause any issues.

If we go that way, I think we should have a big warning that this will mass delete all items assigned to that group. I was not aware that we had such a 'nuclear' handling in v5 and I'm surprised we did not get many complaints.

I agree. We can add a confirmation message before deleting groups.

Surely only the relationship between the groups and items is getting deleted, not the actual items? That said, what purpose does it serve having orphaned items?

Maybe we need both in a modal: ask the user if they want to delete only the group or group + all items in the group too. (Need to make sure, items with more then one group assignment are not deleted but just removed from the particular group!)

Thank you for the interesting discussion. I am still convinced that the current proposal (delete the links, possibly creating orphans) is the way to go. Making the action configurable makes things a lot more involved. I don't think it'll happen in reality that users want to mass-delete lists they have added manually one-by-one. If they are a lot, they may have interacted with the database directly (sqlite3 ...) in which case they can still do what they want.

This said unless we agree on

In my opinion the current v6 way is the right one: don't allow to delete groups which still have items assigned to them.

But we should improve the error message (as in amend the SQL provided message with some that users unterstand)

That said, what purpose does it serve having orphaned items?

That would be a good question to ask at https://discourse.pi-hole.net/t/deleting-a-group-is-not-possible-ftl-v6-0-4/77171/8

In fact, all of the questions and suggestions would be good to discuss there to ask the people requesting this feature how it would best work for them.

Was there a consensus reached on this? I'm still in favor of it.

I've no strong feelings - no blocker from me!

The poll was open 8 days. 62% voted for this PR, 38% for status quo. Nobody wanted a cascade that'd finally delete possible sorphans.

Ok, if we go forward with this change: should we add a modal to inform the user about the change in behavior? We came up with 3 different variants what 'deleting' a group could mean - we should inform the users what will happen and give them a chance to cancle.

Something like
'Deleting this group will un-assign all lists/clients/adlists from this group without deleting them. This could create orphan items which need to be deleted manually. Proceed/Cancle'

IMO such a dialog may have been necessary in the case of possible mass-deletion. My feeling is that we won't need it here. Orphans are no issue at all and the users gets what they ask for: the group they want to delete is ... deleted.

Orphans are no issue at all

I agree. Some users can even add domains not assigned to any groups and later decide how to group them.