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

Thu Mar 10 14:49:04 GMT 2016

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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20160310/ec9320ae/attachment.html>