New Ticket Flow

Following the actual flow to create a new ticket. This page is more for common understanding of what happens and should serve as a base to strain for better integration.

1. Post to /newticket

The POST to the /newticket url is intercepted by the AgiloTicketModule._process_newticket_request() that delegates the request to the TicketModule._process_newticket_request() from Trac. This module is creating a new AgiloTicket object.

2. Creating a new AgiloTicket

The ticket is initialized without a type, as Trac doesn't give more importance to this field as to any other. Unfortunately this generates a list of "unoptimized" calls in the following flow. The values field of the AgiloTicket is initialized using the TicketValueWrapper and being the ticket a new one, the next operation will be to retrieve all the ticket fields, based on the ticket type (which has not been set yet).

3. Getting the ticket allowed fields

The newly created ticket will request AgiloTicketSystem.get_ticket_fields() the fields allowed for its type - which again it is not set. The Ticket System will load from the DB and the config file trac.ini - if not already cached - the fields defined for the ticket - all of them - and will initialize a FieldWrapper - without any type yet.

4. Getting the Agilo fields per type

The FieldWrapper will initialize by asking to AgiloConfig.TYPES with an empty type, that will return no field at all. This will set all the fields available in the FieldsWrapper. Now returning to the ticket, the initialization continue by loading the default values.

5. Initialize the default values for the ticket

The AgiloTicket will now delegate to the Trac Ticket to initialize the ticket with default values - set from the user in the config or DB. The call to Ticket._init_default() will set all the default for the ticket properties, including the ticket type. Setting the default for the ticket type will call the TicketValueWrapper that will call AgiloTicket._reset_type_fields() to reset the ticket fields to the default type (probably the wrong one). This call will cause a load of the fields for the default type, from the AgiloTicketSystem.get_ticket_fields() again. This time we have a type though and the FieldsWrapper will initialize for that type (the default one still, might be the wrong one). This will read again the fields from the DB and the config, and check against the AgiloConfig.TYPES which types to load.

6. Update the value fields of the ticket

The fields for the type are returned into the ticket and after this AgiloTicket._update_values_from_fields_on_type_change() will remove the ticket._old dictionary entries which eventually refer to an old ticket type (this is used to support type change).

7. Load the Agilo virtual properties

The ticket will now load the Agilo "virtual" properties from the config file, including the fields to show on a link, the allowed links and the calculated properties.

Now the ticket is initialized, with a default type (task by default in Agilo), and the creation process continue by populating the ticket with the values received from the web post...

8. Ticket population with posted values

The values received from the web POST are passed to the Ticket.populate(values) that will fill the ticket by accepting only the ones matching the ticket.fields names. The remaining values won't be added to the ticket (This is where I guess we are loosing data). At this point if the fields have not been reset correctly the data will be dropped, because not considered valid for the ticket, as not members of the ticket.fields.

Last modified 10 years ago Last modified on 02/25/2011 10:50:05 AM

1.3.15 © 2008-2016 Agilo Software all rights reserved (this page was served in: 0.66982 sec.)