[Catalyst] Paradigm question: how to use ResultSet level security based on $c->user?

[will trillich]

Question: when a user logs in to our Catalyst app, he/she should only see
the items he/she is allowed to see. But the only way we can figure how to do
this is to pass $c->user either to the ResultSet methods or to the
FormHandler methods, making the app more and more interdependent... Is there
a better paradigm in the context of a Catalyst app?

Right now we're working this via DBIC ResultSet like so:

package Incident::Schema::DB::ResultSet::Incident;
use base 'DBIx::Class::ResultSet';

sub *security* {
    my $rs      =3D shift;
    my $user    =3D shift;

    $user =3D $user->obj
        if ( $user->can('obj') );
    if ( $user->is_admin ) {
        return $rs; # everything is visible to admins
    }

    my %visible_teams =3D map { $_ =3D> 1 }
        $user->corp_team_ids; # method from Incident::User schema
    $rs =3D $rs->search(
        { 'me.team' =3D>
            { -in =3D> [ keys %visible_teams ] }
        },
        { order_by =3D> ['created'] }
    );

    return $rs;
}

Then...

package Incident::Web::Controller::Ticket;
BEGIN { extends 'Catalyst::Controller'; }

sub base : Chained('/auth') PathPart('ticket') CaptureArgs(0) {
    my ( $self, $c ) =3D @_;
    my $rs =3D $c->model('Incident::Ticket')->security( *$c->user* );
    $c->stash( incident_rs =3D> $rs );
}

Is this Kosher? In this context it's a DBIC resultset depending on another
DBIC object, so it may not be as big an issue as, say, when we have
HTML::FormHandler popup menus that should only show the user options based
on the user's role and/or organization.

Is there a canonical way to approach this both in ResultSets and in
FormHandler forms?

-- =

"The very nucleus of Character: to do what you know you should do, when you
don't want to do it." Stephen Covey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20111012/952b9=
08d/attachment.htm