[Vtigercrm-developers] Another migration script query...

Thu Mar 10 15:06:44 GMT 2016

Prasad, you seems to have a diplomatic background... quite cool I must say
:-)

Garry

On Thu, Mar 10, 2016 at 9:49 PM, Prasad <prasad at vtiger.com> wrote:

> Błażej,
>
> Thanks for your time on the reply. Pulling changes from other sources is
> easy if core changes is minimal and aligns with latest working branch.
>
> We will do our best to swim through changes made.
>
> Regards,
> Prasad
>
> --
> FB <http://www.facebook.com/vtiger> I Twit <http://twitter.com/vtigercrm>
>  I LIn <https://www.linkedin.com/company/1270573?trk=tyah> I Blog
> <https://blogs.vtiger.com> I Website <https://www.vtiger.com/>
>
> On Thu, Mar 10, 2016 at 7:04 PM, Błażej Pabiszczak <
> b.pabiszczak at yetiforce.com> wrote:
>
>>
>>
>> Prasad,
>>
>> I don't understand what we are supposed to submit to code.vtiger.com. At
>> the time when we used Vtiger, we submitted fixes, comments, and suggestions
>> for changes. Nobody ever replied to the suggestions, for example what was
>> wrong with them, what we should've fixed, what standards they didn't meet.
>> They were simply never implemented into Vtiger.
>>
>> First of all, YetiForce and Vtiger are currently two different systems;
>> the number of changes we introduced to the original version of Vtiger is
>> almost 10 thousand [some of them are minor fixes, but some other change the
>> logic and functionality]. We add more improvements during a single day,
>> than you during one month. That's why it's impossible for us to add
>> anything to Vtiger, since everything we need, we add to our system. So if
>> you need any changes, you should take them from our GitHub on your own.
>>
>> Secondly, it's not possible to add any changes to your system. When we
>> add something to our system, then every new functionality is reflected in
>> the language files [eg. adding a variable]; whereas part of your modules
>> and language packs [over 30] is in a form of a zipped file, so there's no
>> way to monitor changes and introduce them according to standards, which for
>> us are internal. We also rely on https://github.com/php-fig/fig-standards
>> to a large extent. The code you add to Vtiger omits many standards, also on
>> PHP level [eg. We write PHP code compatible with at least PHP 5.5, your
>> code is usually still on the PHP level that's not officially supported].
>>
>> Another thing is that we now treat Vtiger as a library - when a new
>> version comes out we take whatever we consider decent, and we omit the
>> whole rest. Transferring most changes requires many code improvements,
>> because 90% of our functionalities in our system work differently than in
>> original Vtiger, that's why adding changes to code.vtiger.com requires a
>> lot of alterations each time, in comparison to changes that we implement.
>> Vtiger doesn't develop the open source version, the number of changes
>> introduced for the past year, is 2 – 3 weeks of work of one programmer, and
>> that's just too slow for us.
>>
>> Therefore there's no business justification for why we should add any
>> changes to vtiger.code.com. If there is one however – I'm all ears.
>> ---
>> Z poważaniem / Regards
>>
>> *Błażej Pabiszczak*
>> *Chief Executive Officer*
>> M: +48.884999123
>> E: b.pabiszczak at yetiforce.com
>> ------------------------------
>>
>>
>>
>> W dniu 2016-03-08 06:02, Prasad napisał(a):
>>
>> Błażej,
>>
>> It would be of great assistance if you can merge with latest trunk
>> on code.vtiger.com and submit the merge request.
>>
>> Regards,
>> Prasad
>>
>> --
>> FB <http://www.facebook.com/vtiger> I Twit <http://twitter.com/vtigercrm>
>>  I LIn <https://www.linkedin.com/company/1270573?trk=tyah> I Blog
>> <https://blogs.vtiger.com> I Website <https://www.vtiger.com/>
>>
>> On Tue, Mar 8, 2016 at 6:06 AM, Błażej Pabiszczak <
>> b.pabiszczak at yetiforce.com> wrote:
>>
>>>
>>>
>>> I reported errors related to migrating scripts repeatedly. This is a
>>> fragment of my mail from 2014:
>>>
>>> *Cooperation - part 1*
>>>
>>> "Although we sent ready-made solutions for migration errors from 5.4
>>> version to 6.0 version to vtiger-list, they were not corrected for months
>>> and I will leave it with no comments."
>>>
>>> I understand why Vtiger launched code.vtiger.com, they simply wanted a
>>> few months without complaints. What I don't understand is why you still
>>> have hopes, despite this kind of developer's attitude.
>>>
>>> 1. Why hasn't anybody transferred the errors from
>>> http://trac.vtiger.com/ to http://code.vtiger.com?
>>> 2. Why doesn't anybody verify changes introduced to the current version
>>> of the system?
>>> 3. Why hasn't anybody added and fixed the security errors reported by me
>>> to the mailing list?
>>> 4. Why doesn't anybody introduce new functionalities to the system?
>>> 5. Why doesn't anybody improve the low quality code, that's been in the
>>> system for years?
>>>
>>> So my question to you, Alan, is – what do you think is going to change
>>> in 2016? And what is going to change in 2017? What do you think CRMs in
>>> 2017 will look like, and where will Vtiger be then? And the most important
>>> – what can you do to make Vtiger change their attitude towards the
>>> community and the open source version, which has been simply abandoned.
>>> ---
>>> Z poważaniem / Regards
>>>
>>> *Błażej Pabiszczak*
>>> *Chief Executive Officer*
>>> M: +48.884999123
>>> E: b.pabiszczak at yetiforce.com
>>> ------------------------------
>>>
>>> W dniu 2016-03-04 11:47, Alan Lord napisał(a):
>>>
>>> This is totally bonkers...
>>>
>>> When you install a clean version of vtiger, say version 6.4.0, what I
>>> discovered recently is that the installation process runs all the migration
>>> scripts as well!
>>>
>>> See: http://code.vtiger.com/vtiger/vtigercrm/issues/86
>>>
>>> Recall that in 540_to_600RC.php there is the bit of code I mentioned
>>> before which is losing *critical* information when it migrates old comments
>>> from the vtiger_ticketcomments to the standard vtiger_modcomments table...
>>>
>>> Very shortly *after* the above piece of code is a bit which adds the
>>> "customer" field (that holds the Contact ID) into the ModComments module!
>>>
>>> In the ModComments Module zipped package file it creates the
>>> vtiger_modcomments table with the following SQL
>>>
>>>
>>> CREATE TABLE `vtiger_modcomments` (
>>> `modcommentsid` int(11) DEFAULT NULL,
>>> `commentcontent` text,
>>> `related_to` varchar(100) NOT NULL,
>>> `parent_comments` varchar(100) default NULL
>>> ) ENGINE=InnoDB DEFAULT CHARSET=utf8
>>>
>>>
>>> There are three further columns which are being added to this table via
>>> the migration script (but only after the data has been copied from tickets
>>> and faq records)!
>>>
>>> 'customer', 'userid', 'reasontoedit'
>>>
>>> Over the years I have pointed out that there are several very major, and
>>> loads of minor, errors in these migration scripts and from what I can tell
>>> none of them have been incorporated as yet (please see the archive of this
>>> list for more information).
>>>
>>> What has really surprised me recently is that these scripts are being
>>> run during a fresh, clean installation too!
>>>
>>> Why?
>>>
>>> Why hasn't, for example, the ModComments module package been updated so
>>> that when we install 6.4.0 it creates all the necessary columns?
>>>
>>> It means that none of the standard vtiger modules which are installed on
>>> a new system have a particular *version*. Because, in this case,
>>> ModComments is updated from the 540_to_600RC.php script after it is
>>> installed.
>>>
>>> This seems completely bonkers to me...
>>>
>>> Al
>>>
>>>
>>> _______________________________________________
>>> http://www.vtiger.com/
>>>
>>>
>>> _______________________________________________
>>> http://www.vtiger.com/
>>
>>
>> _______________________________________________
>> http://www.vtiger.com/
>>
>>
>> _______________________________________________
>> http://www.vtiger.com/
>>
>
>
> _______________________________________________
> http://www.vtiger.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20160310/0ae950ad/attachment-0001.html>