Group management not being applied

[mattbxd]

Completely clean install of Pihole v5.1.2, Interface 5.1.1, FTL 5.2

The whitelist script now adds itself into its own group. However, this group can not be applied to clients.

Example)

I now have two Groups. "Default" and "anudeepND/whitelist"

If I go to Group Management -> Clients

and I attempt to apply both Groups to a client, after clicking "Apply", Pihole will say "Successfully edited groups of client" but the selection box itself doesn't change. It stays on "Default".

Thus, the whitelist is now no longer being applied to any client.

If I go to Group Management -> Domains

and attempt to manually apply each whitelist domain, the same thing happens.

In conclusion, since the whitelist domains are in their own group but the group can not be applied to any client and therefore the whitelist is not working. Everything on the whitelist is currently being blocked if they are in one of the adlists. (ex s.youtube.com)

I believe it is based on the following pull request

https://github.com/anudeepND/whitelist/pull/183

[Couto]

Can confirm, I just ran the script, the domains were added, the anudeepND/whitelist group was created and assigned to each imported domain, but I can't apply it to any client (UI reports success, but the group is not actually applied), manually created groups still work fine.

[anudeepND]

I have reverted the PR that created group while installing. If anyone wants to remove the group, you can run this command in the terminal:

sqlite3 /etc/pihole/gravity.db "DELETE FROM 'group' WHERE id = 2552552551;"

[mwoolweaver]

Sorry about this. I wasn't aware of

The ID is automatically generated sequentially when you create the group

what @dschaper said is not stated in the documentation so my thinking was I could use a predetermined value for the groupID but it seems that's not the case so I will rework this so that it adds the group and then check for the ID afterwards.

[dschaper]

The database schema is the documentation.

[mwoolweaver]

correct

https://docs.pi-hole.net/database/gravity/groups/

but I don't see the below quote anywhere.

The ID is automatically generated sequentially when you create the group

[dschaper]

Then it should have come up when you tested your changes.

[dschaper]

dan@raspberrypi:~ $ sudo sqlite3 /etc/pihole/gravity.db ".schema group"
CREATE TABLE IF NOT EXISTS "group"
(
        id INTEGER PRIMARY KEY AUTOINCREMENT,
        enabled BOOLEAN NOT NULL DEFAULT 1,
        name TEXT UNIQUE NOT NULL,
        date_added INTEGER NOT NULL DEFAULT (cast(strftime('%s', 'now') as int)),
        date_modified INTEGER NOT NULL DEFAULT (cast(strftime('%s', 'now') as int)),
        description TEXT
);
CREATE TRIGGER tr_group_update AFTER UPDATE ON "group"
    BEGIN
      UPDATE "group" SET date_modified = (cast(strftime('%s', 'now') as int)) WHERE id = NEW.id;
    END;
CREATE TRIGGER tr_group_zero AFTER DELETE ON "group"
    BEGIN
      INSERT OR IGNORE INTO "group" (id,enabled,name) VALUES (0,1,'Default');
    END;

[mwoolweaver]

again as i said previously that schema is not properly represented in the documentation

https://docs.pi-hole.net/database/gravity/groups/

[dschaper]

That's why you check the schema and test your changes before assume things. Do you really want to argue the point with me?

[mwoolweaver]

you said

The database schema is the documentation.

and now you say

That's why you check the schema and test your changes before assume things.

not much to argue with... the docs aren't accurate... end of discussion...

[dschaper]

The database schema, that I just printed out for you, is the documentation. That's the definitive table of truth for any database. Something you check before you pump data blindly in to one. You also picked an integer that is over the maxint for a signed integer on a 32 bit platform.

We can only document so much and trust that people will look before they do things like blindly pump data in to a database and then not actually check their changes to see if it breaks the entire operation of the application. In this case perhaps we assumed too much.

[mwoolweaver]

In this case perhaps we assumed too much.

so did I...

[SodaWithoutSparkles]

So how could I solve that? I want to revert the changes so that I could use the group management normally Referenced by this Reddit post

[mwoolweaver]

can you run

sqlite3 /etc/pihole/gravity.db "SELECT * FROM 'group';"

and post the output?

[SodaWithoutSparkles]

0|1|Default|1606123676|1606123676|
3|1|Smart Home|1595830800|1606123676|
4|1|bypass|1595831059|1606123676|
6|1|Bypass Google Ad service|1606141006|1607000807|

Ran the command from readme.md to remove the group. Done already. The new groups that added after using whitelist.py was removed using the same command from readme.md but replaced the ID with the new group ID shown on the web GUI. Still unable to apply group changes.

[SodaWithoutSparkles]

Okay, I solved that. First I did a backup from the teleporter page. I then did a reconfigure(pihole -r), selecting the same settings as before. It should not change any of your settings. You may restore the backup, but I didn't need to. That solves it.