Difference between revisions of "Freeside:1.9:Documentation:Developer/FS/part event/Condition"

Revision as of 16:27, 3 October 2007

NAME

FS::part_event::Condition - Base class for event conditions

SYNOPSIS

package FS::part_event::Condition::mycondition;

use base FS::part_event::Condition;

DESCRIPTION

FS::part_event::Condition is a base class for event conditions classes.

METHODS

These methods are implemented in each condition class.

description

Condition classes must define a description method. This method should return a scalar description of the condition.

eventtable_hashref

Condition classes must define an eventtable_hashref method if they can only be tested against some kinds of tables. This method should return a hash reference of eventtables (values set true indicate the condition can be tested):

 sub eventtable_hashref {
   { 'cust_main'      => 1,
     'cust_bill'      => 1,
     'cust_pkg'       => 0,
     'cust_pay_batch' => 0,
   };
 }

option_fields

Condition classes may define an option_fields method to indicate that they accept one or more options.

This method should return a list of option names and option descriptions. Each option description can be a scalar description, for simple options, or a hashref with the following values:

label - Description

; type - Currently text, money, checkbox, checkbox-multiple, select, select-agent, select-pkg_class, select-part_referral, select-table, fixed, hidden, (others can be implemented as httemplate/elements/tr-TYPE.html mason components). Defaults to text.:; options - For checkbox-multiple and select, a list reference of available option values.:; option_labels - For checkbox-multiple (and select?), a hash reference of availble option values and labels.:; value - for checkbox, fixed, hidden (also a default for text, money, more?):; table - for select-table:; name_col - for select-table:; NOTE: See httemplate/elements/select-table.html for a full list of the optinal options for the select-table type

NOTE: A database connection is not yet available when this subroutine is executed.

Example:

 sub option_fields {
   (
     'field'         => 'description',

     'another_field' => { 'label'=>'Amount', 'type'=>'money', },

     'third_field'   => { 'label'         => 'Types',
                          'type'          => 'checkbox-multiple',
                          'options'       => [ 'h', 's' ],
                          'option_labels' => { 'h' => 'Happy',
                                               's' => 'Sad',
                                             },
   );
 }

condition CUSTOMER_EVENT_OBJECT

Condition classes must define a condition method. This method is evaluated to determine if the condition has been met. The object which triggered the event (an FS::cust_main, FS::cust_bill or FS::cust_pkg object) is passed as the first argument. Additional arguments are list of key-value pairs.

To retreive option values, call the option method on the desired option, i.e.:

 my( $self, $cust_object, %opts ) = @_;
 $value_of_field = $self->option('field');

Available additional arguments:

 $time = $opt{'time'}; #use this instead of time or $^T

 $cust_event = $opt{'cust_event'}; #to retreive the cust_event object being tested

Return a true value if the condition has been met, and a false value if it has not.

condition_sql EVENTTABLE

Condition classes may optionally define a condition_sql method. This class method should return an SQL fragment that tests for this condition. The fragment is evaluated and a true value of this expression indicates that the condition has been met. The event table (cust_main, cust_bill or cust_pkg) is passed as an argument.

This method is used for optimizing event queries. You may want to add indices for any columns referenced. It is acceptable to return an SQL fragment which partially tests the condition; doing so will still reduce the number of records which much be returned and tested with the condition method.

implicit_flag

This is used internally by the once and balance conditions. You probably do not want to define this method for new custom conditions, unless you're sure you want every new action to start with your condition.

Condition classes may define an implicit_flag method that returns true to indicate that all new events should start with this condition. (Currently, condition classes which do so should be applicable to all kinds of eventtables.) The numeric value of the flag also defines the ordering of implicit conditions.

remove_warning

Again, used internally by the once and balance conditions; probably not a good idea for new custom conditions.

Condition classes may define a remove_warning method containing a string warning message to enable a confirmation dialog triggered when the condition is removed from an event.

order_sql

This is used internally by the balance_age and cust_bill_age conditions to declare ordering; probably not of general use for new custom conditions.

order_sql_weight

In conjunction with order_sql, this defines which order the ordering fragments supplied by different order_sql should be used.

BASE METHODS

These methods are defined in the base class for use in condition classes.

cust_main CUST_OBJECT

Return the customer object (see FS::cust_main) associated with the provided object (the object itself if it is already a customer object).

option_label OPTIONNAME

Returns the label for the specified option name.

condition_sql_option

This is a class method that returns an SQL fragment for retreiving a condition option. It is primarily intended for use in condition_sql.

NEW CONDITION CLASSES

A module should be added in FS/FS/part_event/Condition/ which implements the methods desribed above in "METHODS". An example may be found in the eg/part_event-Condition-template.pm file.

POD ERRORS

Hey! The above document had some coding errors, which are explained below:

Around line 241:

'=item' outside of any '=over'

Around line 260:

You forgot a '=back' before '=head1'