I backed up to a simple test script, got easier to find errors, and
found the trouble with what I was doing.
__PACKAGE__-many_to_many(roles = 'user_roles', 'name');
needed to be
__PACKAGE__-many_to_many(roles = 'user_roles', 'role');
and a corresponding many_to_many in Role.pm
Continuing saga. So I set up the many_to_many and lo! It worked. But
it worked with *any* role, even fake ones, so obviously something was
bad. Turned out that it was silently failing instead of throwing an
access exception (but there was a template set by the namespace so
the page
Hi Ashley,
The log message you see is a result of the recent move away from the
Catalyst::Plugin::Authentication namespace for stores / credentials.
It falls back to the old naming and warns if it can't find the new
module.. It should, however, have no effect on the functionality of
the
Thanks for still looking at this, Jay. This is the top of the method
with some die decoration:
Take 1:
my ( $self, $c ) = @_;
die This will die;
$c-assert_user_roles(no such role);
Take 2:
my ( $self, $c ) = @_;
$c-assert_user_roles(no such role);
die This will not
While I don't use the DBIx::Class::Loader, I did notice that since the
Catalyst::Plugin::Auth refactor, that set of modules doesn't like dealing
with role_id's any longer. I ended up creating a database view (and
corresponding DBIC class) that spits out role names rather than role IDs,
and
Hi There Ashley,
The DBIx::Class module expects to use the relation provided in the
role_relation config element to retrieve one or more rows, which must
contain a field called by whatever you provide in role_field.
My guess is that your user_roles table is a cross-ref table - userid
and
