Storing a request for later execution

Rails
1

Hi all, I’m looking for ideas.

I want to implement a simple, but generic moderation system for RESTful
rails controllers. Under certain circumstances, when a user submits a
request (beit a GET/POST/PUT/DELETE), the request should not be executed
until an administrator has given the action the all clear.

I was thinking of implementing this as follows:

  • The user submits a request.

  • The controller detects that the user is not an administrator and,
    rather than executing the request, stores it in a “Requests” table.

  • The requests table has columns including the following:
    resource :string # name of RESTful model class that this
    request effects
    action :string # one of “get”, “put”, “post”, “delete”
    parameters :text # a stringified version of the params hash
    passed to the controller

  • Then, an admin can either disallow the request (which deletes it from
    the “Requests” table) or authorize it which will action it (perhaps
    immediately, or alternatively flag it for actioning by a cron script)

  • Upon actioning, a request can be reconstituted and submitted (with
    admin authority so it is not re-inserted to the “Requests” table) to the
    controller.

Has anyone done anything like this? Are there better ways of doing it?
What’s the neatest way to stringify and then reconstitute the params
hash?

I’d be really grateful for any help from anyone who’s read this far!

Nat

2

Why not just model it in a regular CRUD way? I’d prefer a more regular
approach myself to keep things simple and CRUD.

What kind of requests (POST, PUT, DELETE) do you want moderated
anyway?

Erik

3

I think I’m trying to model things in a CRUD way, using RESTful
controller APIs as much as possible.

The background is this: many bulletin board systems allow users to
submit articles or make comments, but their contributions only appear
after a moderator has checked that they aren’t inflamatory, inciteful,
p*rnographic etc etc. I would like to implement a similar(ish) scheme,
but one that is generic.

I want users to be able to manipulate resources (e.g. submitting
articles, adding comments, updating details, deleting obsolete
information), but I want to implement the moderative process in a
generic way, i.e. one that can work with any resource whose controller
follows the RESTful API, and I want to be able to enforce moderation on
some, or all of the 4 CRUD operations (depending on the resource).

For a single type of resource, “articles” for example, it would be
tempting to implement a simple moderation system by including a column
in the “Articles” table that flags whether an article has passed
moderation. Then, only articles which are deemed to be okay (by the all
wise moderator) are displayed to users.

Fine, and simple enough to implement.

But what if I also want users to be able to delete articles? I would
like a moderator to have to okay the deletion before it occurs, so users
can’t delete any article they fancy, only ones whose deletion they can
justify.

The previous sentence gives a hint at the power a more sophisticated
system might provide: If an action (any of the 4 CRUDs) on any relevant
resources (e.g. articles, comments, users, pictures, tasks, etc etc) is
itself treated as a resource in a “meta” table–called perhaps,
“Requests”–then attributes of each request record might include
meta-data such as a text field where a user explains why they think an
action should be performed (i.e. users can justify their actions). Other
users can view proposed actions and provide peer-review of them (by
adding comments), and after some kind of consulation process (perhaps
even a vote) the action can either be binned or executed.

For example, think Wikipedia. A user wants to alter an entry. Rather
than just being allowed to do it, open their submission to peer review,
and only then decide whether the update should be allowed or not.

Similarly, a user finds an article offensive. They propose to delete it.
Other users (and administrators!) can view their arguments for deletion
and then decide whether to act or not.

Many collaborative systems cope well with Create and Read, so-so with
Update and not at all with Delete.

I’m trying to figure out the design of the “Request” table, and the
interaction with moderated Controller and Model classes.

I’m also trying to find out if there’s a much more obvious, but
nonetheless powerful, way of doing this that someone cleverer than me
can suggest.

Nat