Removed adlists not being disabled when using GROUP_ID?

[count0x30]

Removed adlists remain enabled for me, but pihole-updatelists is claiming that they're disabled.

For example:

SQL Query: SELECT * FROM `adlist` WHERE `enabled` = 1 AND `comment` LIKE "%Managed by pihole-updatelists%"
SQL Query: SELECT * FROM `adlist` LEFT JOIN `adlist_by_group` ON `adlist`.`id` = `adlist_by_group`.`adlist_id` WHERE `adlist`.`enabled` = 1 AND `adlist_by_group`.`group_id` = 1
SQL Query: DELETE FROM `adlist_by_group` WHERE `adlist_id` = 61 AND group_id = 1
Disabled: https://v.firebog.net/hosts/Airelle-hrsk.txt

However, pihole-updatelists does remove the adlists' group_id = 1 assignment, leaving them in just the Default group 0. Running pihole-updatelists again doesn't make any changes.

[jacklul]

Can you post your configuration?

[count0x30]

ADLISTS_URL="
https://v.firebog.net/hosts/lists.php?type=nocross
/etc/pihole/custom-adlists.list
"

GROUP_ID=1

VERBOSE=true

LOG_FILE="-/var/log/pihole-updatelists.log"

[jacklul]

Please try the develop branch - pihole-updatelists --update --git-branch=develop, this will be merged into master at a later date. However, it might not correct the mistake right now but should work for future cases.

[count0x30]

Thanks, unfortunately an apt upgrade completely broke my only pi. May take me a couple days to try this out.

[count0x30]

I tried out the develop branch, and it fixes the problem of disabling removed lists.

However, it brings back the behavior from a previous version that I mentioned here #93 . Every time the script runs, it re-applies GROUP_ID. When I started using using pihole-updatelists several versions ago, the script would only apply GROUP_ID upon insertion of a new adlist, and it wouldn't touch the group assignment of existing adlists.

[jacklul]

The problem is that I moved from disabling the lists to removing them from groups to support multiple configurations, especially when lists contents can overlap.

I guess I'll look for a solution when I get time for it

[jacklul]

I've modified how PERSISTENT_GROUP=false works (PERSISTENT_GROUP=true is left intact), it should now not re-add to the groups as long there is manually assigned group to the entry. Please, if you can, test it on your setup (develop branch). Make sure to set PERSISTENT_GROUP=false in the config as true is now the default value.

[count0x30]

Looks good, thank you!

With GROUP_ID=1 and PERSISTENT_GROUP=false:

• New adlist gets inserted with groups 0 and 1
• Existing adlist with modified group assignment is unchanged
• Removed adlist with 0 and 1 group assignment becomes disabled
• Removed adlist with modified group assignment becomes disabled
• Re-added adlist becomes re-enabled with groups 0 and 1

This behavior makes sense to me and works very well for my use-case.

I noticed that when an adlist is disabled by the script, the group assignment gets completely wiped, and the Web UI shows "none selected". Is it possible to disable an adlist programmatically while leaving the group assignment untouched? But that's an incredibly minor issue and just a matter of preference.

[jacklul]

Removed adlist with modified group assignment becomes disabled

Pretty sure this shouldn't happen though even if it matches your use-case, gotta check on this

Edit: just checked it and it stays enabled, just how it should

I noticed that when an adlist is disabled by the script, the group assignment gets completely wiped, and the Web UI shows "none selected". Is it possible to disable an adlist programmatically while leaving the group assignment untouched? But that's an incredibly minor issue and just a matter of preference.

No, this system is specifically put into place so that while the script still keeps a sync with remote lists for specific group (and default group) the user can still use the same entries for their own custom groups and that custom setup should not be touched at all by the script, that's why the script removes the entries that should be disabled from the groups defined in the config, when entry has no custom groups assigned it ends up disabled with 0 groups.