Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Currently the abuse flag settings are stored in the variable table with a separate row for each admin operation. This could cause quite a performance concern for a site with large amounts of content. A separate table should be used to store this data.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | flag-abuse-1074242-whitelist-as-flags-5.patch | 75.59 KB | dalinian |
| #4 | flag-abuse-1074242-whitelist-db-storage-4.patch | 8.23 KB | q0rban |
| #3 | flag-1074242-whitelist-db-storage-3.patch | 8.13 KB | q0rban |
Comments
Comment #1
q0rban commentedComment #2
q0rban commentedBumping this up to major and un-assigning myself.
Comment #3
q0rban commentedOk, here's a first pass at this. I'd like to get some people to test this with real data, as unfortunately I don't have any yet. :/
Comment #4
q0rban commentedTake 2.
Comment #5
ezra-g commentedThis needs work per #1194566: Remove "Reset" functionality.
I suggest we implement the "whitelist" functionality...as a flag.
Comment #6
dalinian commentedFollowing up on the last comment, I've made a patch that implements whitelisting using flags. It allows for both flags 2 and 3 apis and incorporates whitelisting into the administrative views. I patched this against the 7.x-2.x branch and encourage someone to take a look at it. If it works as expected, I think we can go ahead and make at least a beta release of this module.
I ended up creating views for both apis, though I think it's close to time that we stop supporting flags 2.
Comment #7
dalinian commentedComment #8
dalinian commentedI'm going to go ahead and roll this patch into the development version, and subsequently create a 7.x-2.0 release. Since we haven't had any bug reports from the last set of commits, I think this can be released as a full version.
Comment #9
dalinian commentedThis is now in the full release.