My favorites | Sign in
Project Home Downloads Wiki Issues Source
Search
for
TriggerIntegration  
Blueprint for Trigger Integration.
Phase-Design, Deprecated
Updated May 29, 2010 by cedkrier@gmail.com

Implemented in series 1.7

Introduction

This document will provide propositions to integrate into Tryton generic trigger functionality.

Trigger Definition

A trigger is linked to one model. It will be run if its condition will be satisfied. It will be possible to specify that a trigger can be run only once per model. It will define trigger action.

Trigger Conditions

A trigger will have a condition that will be evaluated to determine if the action must be executed.

On create, if the condition is evaluated to true after the creation then the action is executed.

On write, if the condition is evaluated to false before the write and to true after, then the action is executed.

On delete, if the condition is evaluated to true before the deletion, then the action os executed.

Example of condition:

state == 'draft'
amount > 1000
parent.amount > 1000

On time, the condition will be evaluated by a cron task.

Example of condition:

now - create_date > 3600

Trigger Action

It will define a model on which trigger will call a function with this signature:

       def fnct(self, cursor, user, model, ids, trigger_id, context=None)
         '''
         :param cursor: the database cursor
         :param user: the user id
         :param model: the triggered Model
         :param ids: the ids of the triggered record
         :param trigger_id: the id of the trigger record
         :param context: the context
         '''

Trigger Model

class Trigger(ModelSQL, ModelView):
    _name = 'ir.trigger'

    name = fields.Char('Name', required=True)
    model = fields.Many2One('ir.model', 'Model', required=True, select=1)
    on_time = fields.Boolean('On Time', select=1, states={
            'invisible': Or(Eval('on_create', False), Eval('on_write', False),
                    Eval('on_delete', False)),
            })
    on_create = fields.Boolean('On Create', select=1, states={
            'invisible': Eval('on_time', False),
            })
    on_write = fields.Boolean('On Write', select=1, states={
            'invisible': Eval('on_time', False),
            })
    on_delete = fields.Boolean('On Delete', select=1, states={
            'invisible': Eval('on_time', False),
            })
    condition = fields.Char('Condition', required=True)

    action_model = fields.Many2One('ir.model', 'Action Model', required=True)
    action_function = fields.Char('Action Function', required=True)
Comment by project member udo.spallek@gmail.com, Dec 1, 2009

What is the Goal and Function of triggers?

  • Own code based on modification (create, write, delete) could be already triggered by extending the super chain of create, write, delete.
  • Own code based on time could be already triggered by adding a scheduler entry.

Comment by project member cedkrier@gmail.com, Dec 1, 2009

To have a generic behavior.

Comment by project member udo.spallek@gmail.com, Dec 1, 2009

Sorry, I still doesn't understand the goal of triggers.

  1. Can you give me a more deep explanation what can be done with triggers?

2. What is the difference to triggers instead of extending the super chain of create, write, delete or adding a scheduler entry?
3. Why we need triggers?
4. Are triggers applied server-side, client-side or both?
Comment by project member cedkrier@gmail.com, Dec 1, 2009

1. Actions that must be defined (ex: send email/request, call a function, etc.) 2. Writing one code that runs all others. Being more performent (function call is slow). Being generic. 3. It is the same than why do we need Model, we can do SQL or why Report Engine, we can write code etc. 4. I don't understand the question.

Comment by project member udo.spallek@gmail.com, Dec 1, 2009

Thanks cedkrier, now I understand better.

So can I say:

With Triggers we can call existing actions

  • before or/and
  • after
create, write, delete events or based on time.

Comment by project member udo.spallek@gmail.com, Dec 1, 2009

"Writing one code that runs all others." I don't understand.

Comment by project member udo.spallek@gmail.com, Dec 1, 2009

4. Are triggers working only server-side or did they affect client behavoir? But as far as I understand, Triggers are soley server-side.

Comment by project member sharoonk...@gmail.com, Jan 24, 2010

Triggers are extremely important. For example creating a sale order sends confirmation email/small. This could be done by coding (customizing ) or by these triggers (as configuration ) by user. Cedk the design blueprint doesn't talk about how triggers could be called from a workflow. Or is it to ensure one way of doing things?

Comment by project member cedkrier@gmail.com, Jan 24, 2010

I think it is not a good idea to use workflow because: - all Models doesn't have a workflow - in workflow, it often happens that there are more then one activity for a business state (like confirmed sale order or delivered purchase order) - workflow are also Models, so triggers will work also on workflow instances and workflow items

For the example you give, I think the trigger will be when state of sale order change from draft to confirmed.


Sign in to add a comment
Powered by Google Project Hosting