create PARAMHASH

Takes an array of key-value pairs and inserts a new row into the database representing this object.

Overrides Jifty::DBI::Record in these ways:

Remove "id" values unless they are truly numeric

Automatically load by id after create

actually stop creating the new record if a field fails to validate.

id

load_or_create

as_create_action PARAMHASH

The PARAMHASH allows you to add additional parameters to pass to "new_action" in Jifty::Web.

as_update_action PARAMHASH

The PARAMHASH allows you to add additional parameters to pass to "new_action" in Jifty::Web.

as_delete_action PARAMHASH

The PARAMHASH allows you to add additional parameters to pass to "new_action" in Jifty::Web.

as_search_action PARAMHASH

The PARAMHASH allows you to add additional parameters to pass to "new_action" in Jifty::Web.

_guess_table_name

current_user_can RIGHT [ATTRIBUTES]

create

Called just before an object's "create" method is called, as well as before parameter validation. ATTRIBUTES is the attributes that the object is trying to be created with, as the attributes aren't on the object yet to be inspected.

read

Called before any attribute is accessed on the object. ATTRIBUTES is a hash with a single key "column" and a single value, the name of the column being queried.

update

Called before any attribute is changed on the object. ATTRIBUTES is a hash of the arguments passed to _set.

delete

Called before the object is deleted.

Models wishing to customize authorization checks should override this method. You can do so like this:

  sub current_user_can {
      my ($self, $right, %args) = @_;

      # Make any custom checks that return 1 to allow or return 0 to deny...
      
      # Fallback upon the default implementation to handle the
      # SkipAccessControl configuration setting, superuser, bootstrap,
      # delegation, and the before_access hook
      return $self->SUPER::current_user_can($right, %args);
  }

If you are sure you don't want your model to fallback using the default implementation, you can replace the last line with whatever fallback policy required.

Authorization steps

The default implementation proceeds as follows:

1.

If the "SkipAccessControl" setting is set to a true value in the framework configuration section of etc/config.yml, "current_user_can" always returns true.

2.

The method first attempts to call the "before_access" hooks to check for any allow or denial. See "The before_access hook".

3.

Next, the default implementation returns true if the current user is a superuser or a bootstrap user.

4.

Then, if the model can perform delegation, usually by using Jifty::RightsFrom, the access control decision is deferred to another object (via the "delegate_current_user_can" subroutine).

5.

Otherwise, it returns false.

The before_access hook

This implementation may make use of a trigger called "before_access" to make the decision. A new handler can be added to the trigger point by calling "add_handler":

  $record->add_trigger(
      name => 'before_access',
      code => \&before_access,
      abortable => 1,
  );

The "before_access" handler will be passed the same arguments that were used to call "current_user_can", including the current record object, the operation being checked, and any arguments being passed to the operation.

The "before_access" handler should return one of three strings: 'deny', 'allow', or 'ignore'. The "current_user_can" implementation reacts as follows to these results:

1.

If a handler is abortable and aborts by returning a false value (such as "undef"), "current_user_can" returns false.

2.

If any handler returns 'deny', "current_user_can" returns false.

3.

If any handler returns 'allow' and no handler returns 'deny', "current_user_can" returns true.

4.

In all other cases, the results of the handlers are ignored and "current_user_can" proceeds to check using superuser, bootstrap, and delegation.

check_create_rights ATTRIBUTES

check_read_rights

Passes "column" as a named parameter for the column the user is checking rights on.

check_update_rights

check_delete_rights

as_user CurrentUser

as_superuser

delete PARAMHASH

brief_description

To change what this returns, override _brief_description instead.

_brief_description

You can override this method to return the name of a method on your record class which will return a nice short human readable description for this record.

null_reference

_new_collection_args

_new_record_args

cache_key_prefix

since

printable_table_schema

table_schema_statements

create_table_in_db

drop_table_in_db

add_column_sql column_name

add_column_in_db column_name

drop_column_sql column_name

drop_column_in_db column_name

schema_version

Jifty's notion of the schema version is currently broken into two:

1.

The Jifty version is the first. In the case of models defined by Jifty itself, these use the version found in $Jifty::VERSION.

2.

Any model defined by your application use the database version declared in the configuration. In etc/config.yml, this is located at:

  framework:
    Database:
      Version: 0.0.1
    

A model is considered to be defined by Jifty if it the package name starts with "Jifty::". Otherwise, it is assumed to be an application model.

column_serialized_as

default_serialized_as_columns

jifty_serialize_format

autogenerate_action

The default method returns 0 for all action classes if the model is marked as "is_private". It returns 0 for all actions that are not "Search" if the model is marked as "is_protected"; otherwise, it returns true.

is_private

is_protected

enumerable