jifty::plugin::comment::mixin::model::commented(3pm) [debian man page]
Jifty::Plugin::Comment::Mixin::Model::Commented(3pm) User Contributed Perl Documentation Jifty::Plugin::Comment::Mixin::Model::Commented(3pm)NAME
Jifty::Plugin::Comment::Mixin::Model::Commented - add comments to a model
SYNOPSIS
package App::Model::Fooble;
use Jifty::DBI::Schema;
use App::Record schema {
column scribble => type is 'text';
column wobble => type is 'int';
};
use Jifty::Plugin::Comment::Mixin::Model::Commented;
DESCRIPTION
Add this mixin to a model if you'd like to attach comments to it. Comments can be used to allow users of your system to comment upon and
discuss the record to which they are attached.
METHODS
import
This method performs some rather devious magic to make everything work easily. It automatically generates an additional model for your
application. This model will look something like this:
use strict;
use warnings;
package App::Model::FoobleComment;
use Jifty::DBI::Schema;
use Jifty::Record schema {
column commented_upon =>
references App::Model::Fooble,
label is 'Commented upon',
is mandatory,
is immutable,
;
column the_comment =>
references App::Model::Comment,
label is 'Comment',
is mandatory,
is immutable,
is distinct,
;
};
App::Model::FoobleComment->add_trigger( before_access => sub {
my $self = shift;
my ($right, %args) = @_;
if ($right eq 'create') {
return 'allow' if $self->current_user->id;
}
if ($right eq 'read') {
return 'allow';
}
return $self->App::Model::FoobleComment::current_user_can(@_);
});
You will need to define an "before_access" trigger for this class if you want it to be useful.
for_commenting
Returns a value to be used with the comment views. It's basically just a string identifying the class name and ID of the record.
comments
Returns a collection of Jifty::Plugin::Comment::Model::Comment objects that have been attached to the current record. (Actually, it returns
the a collection of the local application class, e.g. "App::Model::CommentCollection".)
comment_record_class
This is the name of the linking class that was created during "import".
AUTHOR
Andrew Sterling Hanenkamp "<hanenkamp@cpan.com>"
COPYRIGHT AND LICENSE
Copyright 2007 Boomer Consulting, Inc. All Rights Reserved.
This program is free software and may be modified and distributed under the same terms as Perl itself.
perl v5.12.4 2009-03-09 Jifty::Plugin::Comment::Mixin::Model::Commented(3pm)
Check Out this Related Man Page
Jifty::Manual::AccessControl(3pm) User Contributed Perl Documentation Jifty::Manual::AccessControl(3pm)NAME
Jifty::Manual::AccessControl - Using Jifty's default ACL system
DESCRIPTION
Out of the box Jifty-based applications have an ACL system. The system automatically validates ACLs on Jifty::Record objects by calling
the method "current_user_can" before any create, read, update, or delete operation. In all cases, the arguments passed to the CRUD
operation are passed as extra arguments to "current_user_can".
On "create()", we reject the operation if "current_user_can('create')" returns FALSE.
On "_value()" or "somefieldname", we reject the operation if "current_user_can('read')" returns false.
On "_set()" or "set_somefieldname", we reject the operation if "current_user_can('update')" returns false.
On "delete()", we reject the operation if "current_user_can('delete')" returns false.
Out of the box, "current_user_can" returns 1. When you want to actually check ACLs, you'll need to override "current_user_can()" in your
"Jifty::Record" subclass.
It's likely that at some point, you'll decide you want to ask other questions on certain types of operations. Say, you only want to let
administrators update the "paid_account" field. In that case, you'd override "check_update_rights()" to look for the "admin" right rather
than the "update" right, if the "FIELD" is "paid_account".
ENABLING ACCESS CONTROL USING THE USER PLUGIN
To painlessly enable the AccessControl subsystem, a User plugin is available with an authentication plugin, the "Authentication::Password"
plugin may get enabled. This is done in the etc/config.yml configuration file.
Plugins:
- Authentication::Password: {}
Then, create an "App::Model::User" class that will be override with "Jifty::Plugin::User::Mixin::Model::User" and an authentication plugin
"Jifty::Plugin::Authentication::Password::Mixin::Model::User" , for example:
use strict;
use warnings;
package App::Model::User;
use Jifty::DBI::Schema;
use App::Record schema {
};
use Jifty::Plugin::User::Mixin::Model::User;
use Jifty::Plugin::Authentication::Password::Mixin::Model::User;
# Your model-specific methods go here.
1;
Next, create the table in your database using the jifty executable like "./bin/jifty schema --setup".
Expanding the Model
The model that manages "User" Records is not limited to the plugin's definition. It can be expanded by providing an additional schema
definition. Every column here will be added to the plugin's columns. Simply add a schema definition block like this:
use Jifty::DBI::Schema;
use App::Record schema {
column 'extra_column_name';
column 'mygroup' =>
valid_values are qw/admin moderator user/,
default is 'user';
# more columns if necessary
};
The full syntax for defining a schema can be found in Jifty::Manual::Models or in Jifty::DBI::Schema.
If you want to manage an admin group, you must protect the group column as only a superuser can change it. Then, you override
"current_user_can" in "App::Model::User"
sub current_user_can {
my $self = shift;
my $type = shift;
my %args = (@_);
return 0
if ( $type eq 'update'
and !$self->current_user->is_superuser
and $args{'column'} eq 'mygroup' );
return 1;
}
Defining a method "_init" in your "App::CurrentUser" class gives you a chance to add more data to the "CurrentUser" object. This method
will automatically get called after the Plugin's "_init" is done.
package App::CurrentUser;
use strict;
use warnings;
use base qw(Jifty::CurrentUser);
__PACKAGE__->mk_accessors(qw(group));
sub _init {
my $self = shift;
my %args = (@_);
if (keys %args) {
$self->user_object(App::Model::User->new(current_user => $self));
$self->user_object->load_by_cols(%args);
if ( $self->user_object->mygroup eq 'admin') {
$self->is_superuser(1);
};
$self->group($self->user_object->mygroup);
};
$self->SUPER::_init(%args);
};
With your "App::CurrentUser", users in group admin are superuser and you can use "Jifty->web->current_user->group" in your application.
Templates defined by the "Authentication::Password" plugin
To avoid the need for repetitive work, the "Authentication::Password" plugin already defines a couple of usable templates:
/login
provides a login screen with a signup option. After successful login, the current continuation is called. If no continuation exists,
the template sitting at the base URL (/) is called.
/logout
logs out the current user.
/signup
allows a user to sign up himself/herself. By default a confirmation mail is sent out that has to get followed by the user.
/passwordreminder
after entering his/her mail address, the user will receive a mail that contains a link to /let/reset_lost_password.
/let/confirm_email
is called in the mail and results in accepting the user.
/let/reset_lost_password
enabled by the /passwordreminder template, this template allows a user to reenter a password for future use.
Doing checks at other places in your code
If you need to check more than Model-based record operations you will have to do some coding on your own. "Jifty->web->current_user"
provides a "App::CurrentUser" object that can get queried about the current user. This object provides some convenience methods:
"username"
returns the name of the current user or "undef" if not logged in.
"id"
returns the id of the current user or "undef" if not logged in.
SEE ALSO
Jifty::CurrentUser, Jifty::Record, Jifty::RightsFrom, Jifty::Plugin::Authentication::Ldap, Jifty::Plugin::Authentication::CAS
perl v5.14.2 2010-12-08 Jifty::Manual::AccessControl(3pm)