Re: [Dolibarr-dev] Question about llx_element_contact and multi contact management on Calendar event

[Florian Henry]

Ok, I will answer to myself.

Column llx_element_contact.fk_c_type_contact is unique per object type... So I do not need to add element_type column and there is no migration/upgrade problem...

Sorry to bug all of you with this type of non problem.

Regards

Florian HENRY
address@hidden
+33 6 03 76 48 07
http://www.open-concept.pro
Twitter : @_Open_Concept_
Secretaire de l'association Dolibarr

Le 19/10/2013 11:12, Florian Henry a écrit :

Hi all,

    I'm going to "reactivate" the contact management on calendar event.

        Task DoliForge : https://doliforge.org/tracker/?func=detail&aid=1097&group_id=144

    Actually in dev branch there is a page htdocs/comm/action/contact.php.
    This page is display only withintab's  event card if hidden constant AGENDA_USE_SEVERAL_CONTACTS is enabled, but it's not working...

    I have change the page htdocs/comm/action/contact.php to use the htdocs/core/tpl/contact.tpl.php as it is done in other object (propal/invoice/order/...)

    I'm working on auto assign Guest and Manager to the table llx_element_contact when event is created/updated/deleted (only if option AGENDA_USE_SEVERAL_CONTACTS is enabled of course).

    Here I notice something in the table llx_element_contact, there is no element_type column...

    So if we have a proposal id=1 and affect a contact id =1 we cannot add the same contact on a order id=1 because of uk integrity violation.

    When delete order or proposal all line with element_id=1 will be delete even they are not the concern ones...


    Also, I add a column element_type into llx_element_contact, and upgrade the commonobject.class.php to take this column account when adding,update, or delete. (method delete_contact,update_contact,add_contact)

    My question is how can we do to migrate/upgrade properly the data for this table.

        Here option I can imagine :
        1- Into SQL request of these commonobject methods do something like
             (WHERE element_type='$this->element' OR element_type IS NULL)

            This option will not solve the problem at all, but at least will keep the feature working (and keeping the current problem) and allow the element_type column working as well

        2- Create table llx_actioncomm_contact and do spécific method into class ActionComm.
        More easy but missing uniformize and "factorisation" code goal.

           3- Create a specific migration/upgrade screen to ask to user with what rowid the elemnt_id of element_contact is link with (proposal/order/invoice/project/fiche inter/supplier order/supplier invoice/...), I let you imagine what will be the result of 100000 line in this table...

What is your point of view ??

I would like to put this feature into 3.5, so Laurent, what is the best option ?

Regards