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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

q0rban’s picture

Assigned: Unassigned » q0rban
q0rban’s picture

Assigned: q0rban » Unassigned
Priority: Normal » Major

Bumping this up to major and un-assigning myself.

q0rban’s picture

Title: Use separate table for storage » Use separate table for storing whitelisted content
Status: Active » Needs review
FileSize
8.13 KB

Ok, 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. :/

q0rban’s picture

ezra-g’s picture

Title: Use separate table for storing whitelisted content » Re-introduce whitelisted content
Category: task » feature
Status: Needs review » Needs work

This needs work per #1194566: Remove "Reset" functionality.

I suggest we implement the "whitelist" functionality...as a flag.

dalinian’s picture

Following 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.

dalinian’s picture

Assigned: Unassigned » dalinian
Status: Needs work » Needs review
dalinian’s picture

I'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.

dalinian’s picture

Status: Needs review » Closed (fixed)

This is now in the full release.