# Storing a request for later execution **URL:** \ **Category:** Rails\ **Created:** [April 3, 2007, 7:19pm UTC](https://www.ruby-forum.com/t/storing-a-request-for-later-execution/91002 "2007-04-03T19:19:12Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\ **Post date:** [April 3, 2007, 7:19pm UTC](https://www.ruby-forum.com/t/storing-a-request-for-later-execution/91002/1 "2007-04-03T19:19:12Z")
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 ---
**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\ **Post date:** [April 5, 2007, 10:32am UTC](https://www.ruby-forum.com/t/storing-a-request-for-later-execution/91002/2 "2007-04-05T10:32:21Z")
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 ---
**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\ **Post date:** [April 5, 2007, 5:39pm UTC](https://www.ruby-forum.com/t/storing-a-request-for-later-execution/91002/3 "2007-04-05T17:39:25Z")
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