[Vtigercrm-developers] Another Migration Bug...

[Uma S]

Hi Alan,

We have checked your query against vtiger 530 and vtiger 540 database.
Where block-label value for block-id 20, 40 and 41 is empty. So we are
depending on block-id values directly in query for operations.

We had found a way to resolve this issue where by passing block-id with
module instance we can generate block instance, which can be used during
query operations. I will update this query using block object here in trac
<http://trac.vtiger.com/cgi-bin/trac.cgi/ticket/8641> ticket, which should
be manually updated by user in migration script.


On Wed, Oct 14, 2015 at 8:46 PM, Alan Lord <alanslists at gmail.com> wrote:

> This has failed on several migrations and I am not quite sure I get what
> it is supposed to be doing...
>
> This code is from 540_to_600RC.php:
>
> //Calendar and Events module clean up
>>
>
> $calendarTabId = getTabid('Calendar');
>>
>
> $eventTabId = getTabid('Events');
>>
>
> Migration_Index_View::ExecuteQuery('UPDATE vtiger_blocks SET blocklabel
>> ="LBL_DESCRIPTION_INFORMATION" WHERE blockid=20',array());
>>
>
> Migration_Index_View::ExecuteQuery('UPDATE vtiger_field SET displaytype=1
>> WHERE fieldname="location" AND tabid = ?', array($calendarTabId));
>>
>
> Migration_Index_View::ExecuteQuery('UPDATE vtiger_field SET displaytype=1
>> WHERE fieldname="visibility" AND tabid = ?', array($eventTabId));
>>
>
>
>>
> $eventBlockId = getBlockId($eventTabId, 'LBL_EVENT_INFORMATION');
>>
>
> Migration_Index_View::ExecuteQuery('UPDATE vtiger_field SET block = ?
>> WHERE block = 41', array($eventBlockId));
>>
>
> Migration_Index_View::ExecuteQuery('UPDATE vtiger_blocks SET blocklabel =
>> "LBL_REMINDER_INFORMATION", show_title = 0 WHERE blockid = 40',array());
>>
>
> Migration_Index_View::ExecuteQuery('UPDATE vtiger_blocks SET blocklabel =
>> "LBL_DESCRIPTION_INFORMATION", show_title = 0 WHERE blockid = 41',array());
>>
>
> Migration_Index_View::ExecuteQuery('UPDATE vtiger_field SET block = 41
>> WHERE fieldname = "description" AND tabid = ?',array($eventTabId));
>>
>
> Migration_Index_View::ExecuteQuery('UPDATE vtiger_field SET block = ?
>> WHERE fieldname = "contact_id" AND tabid = ?', array($eventBlockId,
>> $eventTabId));
>>
>
> Migration_Index_View::ExecuteQuery('UPDATE vtiger_field SET displaytype =
>> 3 WHERE fieldname = ? AND tabid = ?', array('notime', $eventTabId));
>>
>
> Migration_Index_View::ExecuteQuery('UPDATE vtiger_field SET displaytype =
>> 3 WHERE fieldname = ? AND tabid = ?', array('duration_hours', $eventTabId));
>>
>
> Note the hardcoded Block IDs in here "40" and "41".
>
> On some systems (which came from 5.3.0 or earlier) this part of the
> process fails because the hardcoded Block IDs are not what is expected.
>
> Block ID 40 is actually for tabid 15 (Faq) and has a label of
> 'LBL_COMMENT_INFORMATION'.
>
> Block ID 41 is is for tabid 16 (Events) and has a label of
> 'LBL_EVENT_INFORMATION'.
>
> So this line:
>
>> Migration_Index_View::ExecuteQuery('UPDATE vtiger_field SET block = ?
>>> WHERE block = 41', array($eventBlockId));
>>>
>> Does nothing at all.
>
> This line:
>
>> Migration_Index_View::ExecuteQuery('UPDATE vtiger_blocks SET blocklabel =
>>> "LBL_REMINDER_INFORMATION", show_title = 0 WHERE blockid = 40',array());
>>>
>> Changes the Comment Information block of the FAQ module to be the
> Reminder Information block (but without changing the tab???
>
> The end result of this little part of code is you have Calendar/Event
> fields which are tied to invalid or invisible blocks.
>
> Then I get confused and end up manually fixing the Calendar fields after
> the migration has completed..
>
> Al
>
> _______________________________________________
> http://www.vtiger.com/
>



-- 
With
Best Regards
Uma.S
Vtiger Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20151015/dad0203f/attachment.html>