# Concern of admin panel management

**URL:** <https://www.ruby-forum.com/t/concern-of-admin-panel-management/137774>\
**Category:** Rails\
**Created:** [May 16, 2008, 8:53am UTC](https://www.ruby-forum.com/t/concern-of-admin-panel-management/137774 "2008-05-16T08:53:20Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Realusers](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/53a042/32.png) [@Realusers](https://www.ruby-forum.com/u/Realusers)\
**Post date:** [May 16, 2008, 8:53am UTC](https://www.ruby-forum.com/t/concern-of-admin-panel-management/137774/1 "2008-05-16T08:53:20Z")

</div>

Dear all,  
I am doing programming in ruby on rails platform from last three  
months . I have spent my last two years in PHP programming where i  
developed many shopping carts. I used to make a different section for  
a normal web site user and special section for administrator. The  
files i used in administrator section were all different than those in  
normal users view.  
Now i have a problem to manage same thing in ruby in rails. Should  
i manage as what i did in PHP? Is there any standard for managing it?  
I feel it is not good to let administrator edit the data from the  
normal users section because we have to spend lot of time maintaining  
the design rather than focusing on the logic.

Please suggest me with the best possible solution for this.

Regards  
Realusers

---

<div class="post-metadata">

**Author:** ![Realusers](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/53a042/32.png) [@Realusers](https://www.ruby-forum.com/u/Realusers)\
**Post date:** [May 16, 2008, 10:39pm UTC](https://www.ruby-forum.com/t/concern-of-admin-panel-management/137774/2 "2008-05-16T22:39:40Z")

</div>

Lots of different ways you could tackle this. I think there isn’t so  
much a “rails standard”… but probably some best practices… or  
“good ideas” at least.

Lets see… off the top of my head:

- namespace admin functionality, both for controllers and views.
- use role-based hooks to define additional checks or functions on  
existing controllers
  - and use an “admin” layout for them

- use something like ActiveScaffold for admin views… provides very  
nice data management
- build a separate admin app that uses the same DB (but otherwise is a  
totally separate rails app)
- punt and use some other DB management tools (for example, on a very  
small project, I just use CocoaSQL to remotely modify data. Not very  
secure, but a perfect fit for the specific project & needs).

Interestingly, I haven’t done any good full-blown admin suites yet.  
I’m working on a large project that will need a very rich admin suite.  
I’m starting to think that the admin suite may be big enough and  
different enough that it will make more sense to run it as a totally  
separate app… probably even on a separate domain. And maybe do some  
funkiness with DBs so that it has some admin tables but also full  
access to the public app’s tables.

The only downside is how to leverage the various code from the public  
app? Hmmm… maybe the public app is “vendor’d” into the admin app?

I guess I too welcome any other thoughts.

-Danimal

---

<div class="post-metadata">

**Author:** ![Realusers](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/53a042/32.png) [@Realusers](https://www.ruby-forum.com/u/Realusers)\
**Post date:** [May 16, 2008, 11:22pm UTC](https://www.ruby-forum.com/t/concern-of-admin-panel-management/137774/3 "2008-05-16T23:22:06Z")

</div>

Danimal wrote:

> Lots of different ways you could tackle this. I think there isn’t so  
> much a “rails standard”… but probably some best practices… or  
> “good ideas” at least.

Being the lead developer, and a user, and (at least initially) the  
admin, I see no reason not to give the admin the same nice interface for  
our intranet app.

My app uses a specific \_left-nav-admin partial for anyone with the  
administrator role which provides the links to all the admin features  
(users, roles, teams, memberships, permissions, etc), and the  
controllers for those models are all locked down with appropriate  
before\_filter settings checking for the admin role.

There is also the fail-safe “Iron Admin” login (created specially in  
migration 001) that no login other than the Iron Admin is allowed to  
tinker with (no changing his roles, password, e-mail, etc), even if your  
login has been granted the admin role. That login isn’t a member of any  
“user” teams either.

Out in the “users” data realm, all logins are subject to the same rules  
as everyone else.

It’s worked out pretty well, and I’ve used the Iron Admin to create data  
that other user’s can review online, or generate a PDF for hardcopy  
(like an online example/tutorial for the application), but no-one else  
can edit or delete that data due to ownership rules.
