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

Fri Mar 11 03:51:41 GMT 2016

I don't find this as cool, I would have appreciated if the outlined issues
with the vtiger open source project were actually addressed and answered.
The strategy of pretending nothing was ever said is not cool at all.

Let me summarize:
- Why were change requests by yetiforce developers on the old trac never
taken? How should this be different now? I have the same feeling long time
already. Only small fixes or improvements here and there are allowed. Major
changes are being ignored. 
- Why are there so little changes being made by the vtiger core developers
themselves? Blazej is right, the amount of changes is ridiculously low
compared to other projects. Most changes actually come from the open source
community members now.
- fig php standards... vtigers code is so little standardized... I even
stopped caring if I do tabs or spaces, no one else seems to care about this
either... and up to date PHP compatibility and even PHP7 compatibility, ever
thought about it?

I am getting sick of the vtiger ignoring strategy. Either not answering
complaints at all or pretending things are going to happen and then nothing
happens... Contribution has never been as painful as in this project. 

Come on guys... make vtiger great again!

Garry Brighton wrote
> 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@

> > 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@

>> 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@

>>> ------------------------------
>>>
>>>
>>>
>>> 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@

>> 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@

>>>> ------------------------------
>>>>
>>>> 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/
>>
> 
> _______________________________________________
> http://www.vtiger.com/

--
View this message in context: http://vtiger-crm.2324883.n4.nabble.com/Vtigercrm-developers-Another-migration-script-query-tp18548p18605.html
Sent from the vtigercrm-developers mailing list archive at Nabble.com.