Abstract the way Abuse stores data to allow modules like the Flag Abuse module to become data storage for the Abuse UI

My two pennorth:

It would be great to see these modules consolidated. At the moment this module has way more (and more relevant) features that Flag Abuse, but the Flag API is a much smarter storage mechanism and opens up more flexibility (views, rules, actions, all core).

Let's look at this the other way around. If you could detach Abuse from its current storage mechanism and allow other modules to present their *own* storage mechanism via an API, suddenly both these modules play nicely together.

You leave the current storage approach as the "default" one, bundled with this module, but you add an API allowing Flag Abuse to provide a storage option using the Flag API. That way Abuse concentrates on being a cool UI, with the storage abstracted, and Flag Abuse becomes a storage mechanism for Abuse (one of potentially several options).

I'm doing similar work on Feedback right now with sun - it might be worth reviewing the issue for inspiration:
#293512: Abstract back-end for integration with 3rd party issue trackers

It's a different issue, but I believe the solution is the same. =)

Arg, forgot to change the status!

Until someone can really step up to take over this module, this isn't really going to happen. And I honestly wish this weren't the case.

As the "maintainer" of the module (the word shouldn't really apply considering the current state of the module), the main issue in all of this is that I am working on a series of different projects and none of them use the abuse module (primarily due to the scope of the projects). As a result, I cannot alone try and maintain something not being used on a day to day basis. I would be happy to work with a set of developers since that is more fun, however.

I completely agree with the idea that the abuse module should let go of the storage mechanism (its storage architecture really is a precusor to what the flag module does) for one extremely important reason: views.

The abuse module has happened to be built for sites that had little (to no) requirement for views. In these cases, I used a frankly stupid mechanism whereby I am modifying the node status to something that views does not recognize (I would like to blame the node module for doing something that allowed does but there is really no one to blame other than myself).

The abuse module would be ready to move towards becoming a content access type of module (though I really need to catch up on something like that) and use the storage mechanism in there to work with all this. But there shouldn't be a need for that.

The abuse module in its current state is primarily covered by what is occurring in the flag abuse module. I do think flag abuse and VBO would make a lovely couple and might be a better way for managing large pieces of content (something abuse does well...but not with views. argh!)

What is not covered (and probably the more useful part of abuse) is the watchlist module (which has its own, albeit smaller, set of issues with some strange php). By pre-assigning pieces of content with abuse flags, it does help out with some level of content premoderation.

So tl;dr: abuse needs to be abstracted; whatever it is abstracted to, allow for watchlist to power that abstraction (since that is something that really helps moderators), glad to work with others in working on this in a sprint like manner, but this module honestly needs a new maintainer.

I'm going to take over this module. However, I don't think it will soon happen. My plan is at #918522: Keep it clean: no more -1 status. I want to keep it clean, small. We may need another table for data storage, but not the Flag module. I'm quite unconfortable to make the module bloat, and I don't know much about Flag now. Besides, doesn't it what Flag Abuse actually do?

About #2, it's even more complicated. Why the UI is not integrated directly into Flag Abuse?

My thought is that Abuse needs to be stable, has a clear data storage. This way it can be converted to base on Flag API or merge into Flag Abuse later.

The point of this is not to remove the current storage mechanism, but to make it possible to plug others. So your comment is maybe fair, but not really relevant, as there is no intent in this issue to change anything about the way Abuse stores information. If you look at the similar thread I referenced in #2 you'll see the approach I am suggesting. Allowing 3rd-party modules the flexibility to "swap out" the Abuse core storage mechanism you're talking about.

I am working on a project for client that needs abuse functions. Like many others we need a bit of both Flag_abuse and the original abuse functions.
Flag abuse with combination of flag_note does provide ability to store comments , however does not provide facility of adding in things like "Reason for reporting" etc.

As a result of this, i am right now writing a bit of custom module that adds in fields for "Reason for reporting", provides better support in rulesets (at the moment flag work well when actions are invoked individually in VBO, but fail if the actions are called as part of ruleset etc.

All along have been thinking it would be so much better if somehow flag_abuse works together with abuse module. I will be happy to join hands on looking at all available options and possibilities.

-Ravi

Just a follow-up here, I got side-tracked in to this queue looking for another patch but sirkitree made the good point in the Flag Abuse queue that there would be no sense in Abuse using Flag Abuse for storage - it should just use Flag directly.

It is also his opinion that both modules (Abuse and Flag Abuse) should be able to co-exist in the same ecosystem, as the latter is a much light module and wholly different in architecture to Abuse - an opinion I think I share. =)