Migration Incompleted. Only on 2 browsers.

[jvidamins]

Getting this message on Firefox and Microsoft Edge when trying to go to corebos install:
Migration Incompleted.  Please contact your system administrator.

Problem is, I completed it successfully, pulled in and installed all the updates, and worked on setting up workflows and a bunch of other stuff for about 5 hours.  I'm still logged in on Chrome and it's working fine.  I haven't logged out from there yet as I'm scared to.  

I just can't access it from the other 2 browsers???  Any idea why or how to fix it?

Loving CoreBOS so far!  Especially the added options with workflow!!!  The ability to check another condition before cron emails are sent out - AWESOME!!!

[joebordes]

I'd say it is a problem with the vtigerversion.php file. This file is updated to be in sync with the database version but if the web user doesn't have permission to write on the file then the database says one thing and the code another. it is kind of strange as we have left this problem behind us a long time ago and you shouldn't run into it, but that would justify the behaviour you are describing.
Effectively, if I am correct, as soon as you logout you will not be able to log in again as this information is stored in the user's session the first time you login.

Look in vtigerversion.php and vtiger_version database table and make sure they say the same thing.

Let me know how it goes.

[joebordes]

Thanks for the positive comments :-)

[jvidamins]

(12-05-2016, 11:37 AM)joebordes Wrote: I'd say it is a problem with the vtigerversion.php file. This file is updated to be in sync with the database version but if the web user doesn't have permission to write on the file then the database says one thing and the code another. it is kind of strange as we have left this problem behind us a long time ago and you shouldn't run into it, but that would justify the behaviour you are describing.
Effectively, if I am correct, as soon as you logout you will not be able to log in again as this information is stored in the user's session the first time you login.

Look in vtigerversion.php and vtiger_version database table and make sure they say the same thing.

Let me know how it goes.

Maybe this a dumb question, but I can't find anything in my database called "vtiger_version".  I did an exact search in all tables.  Where's it located?  If it's truly not there, then what?

---

(12-05-2016, 05:43 PM)jvidamins Wrote:

(12-05-2016, 11:37 AM)joebordes Wrote: I'd say it is a problem with the vtigerversion.php file. This file is updated to be in sync with the database version but if the web user doesn't have permission to write on the file then the database says one thing and the code another. it is kind of strange as we have left this problem behind us a long time ago and you shouldn't run into it, but that would justify the behaviour you are describing.
Effectively, if I am correct, as soon as you logout you will not be able to log in again as this information is stored in the user's session the first time you login.

Look in vtigerversion.php and vtiger_version database table and make sure they say the same thing.

Let me know how it goes.

Maybe this a dumb question, but I can't find anything in my database called "vtiger_version".  I did an exact search in all tables.  Where's it located?  If it's truly not there, then what?

 
Nevermind, it was dumb.    I found it.  It says old_version 5.4.0 and current_version 5.5.0.  I'm assuming I change current_version to 5.4.0?  

This is what my vtigerversion.php file has:

require_once 'include/utils/Session.php';

$patch_version = '';
$modified_database = '';
$vtiger_current_version = '5.4.0';
$coreBOS_app_version = '5.8.0';
$coreBOS_app_name ='coreBOS';
$coreBOS_app_url = 'http://corebos.org';
$coreBOS_commit_info = '$Format:%ci$ ($Format:%h$)';

---

Ok, changing that worked. Thanks Joe! Is there any chance anything else may not have migrated correctly? I have a few more questions, too if you don't mind.

1. I'm assuming that all my queued emails from my workflow/cron transferred over with the database and will be sending out at the same time my vtiger install will be sending them out, right? Which would cause double emailing, which I obviously don't want. I just want to make sure of that before I delete my vtiger install and database.

2. Is it possible to upgrade corebos to vtiger 6 or 7? Not that I want to. Has your opinion of what vtiger has done since you created corebos changed at all? Or do you still think all the latest versions of vtiger fall short and are bad ideas to upgrade to?

3. Not sure if you can help on this one, but I've never figured out how to accomplish this. I have a contact record. As soon as I change the status of one of the fields of that record (Listing Status) to "Pending", I have a workflow that is set to run the "first time the condition is met" and will queue up several emails based on a date field in the record. My problem is, sometimes the "Listing Status" field needs to be changed back to "Active" because the deal falls through. Then, if a new deal comes along and I have to change it back to "Pending", the workflow doesn't run because it's already been met. My solution for the past several years has been to duplicate the contact and delete the old one, so the workflow will run again. There's got to be a better way! Any suggestions?

[joebordes]

(12-05-2016, 05:43 PM)jvidamins Wrote: Ok, changing that worked.  Thanks Joe!  Is there any chance anything else may not have migrated correctly?

I would say that the migration went well and it just couldn't update the file. Make sure you have all corebos changesets loaded and applied. Look in the online demo, you should have the same amount of changesets or more if your code is more up to date than the demo.
The vtiger_version in the file and the database should be 5.5.0

(12-05-2016, 05:43 PM)jvidamins Wrote: 1. I'm assuming that all my queued emails from my workflow/cron transferred over with the database and will be sending out at the same time my vtiger install will be sending them out, right?  Which would cause double emailing, which I obviously don't want.  I just want to make sure of that before I delete my vtiger install and database.

I would say yes. Look in the com_vtiger_queue (or something like that) it should contain the workflows to be launched. Another issue would be to see if they actually go out because we have enhanced so much the workflows that those tasks may be missing fields or something. It would be nice if you could confirm they are working or not.

(12-05-2016, 05:43 PM)jvidamins Wrote: 2. Is it possible to upgrade corebos to vtiger 6 or 7?  Not that I want to.  Has your opinion of what vtiger has done since you created corebos changed at all?  Or do you still think all the latest versions of vtiger fall short and are bad ideas to upgrade to?  

Possible: yes. Easy: no. You would have to go over all the changesets applied and undo them, that is a considerable amount of work.
If I hadn't forked it years ago I would do it now. The vtiger crm project is a bad joke in all senses. The company just doesn't care about the open source project. I really don't understand how intelligent people still keep begging and suffering there. Incredible. Those that say "if my clients asked me for coreBOS I would do that" are doing their clients a bad service.
You just have to look at the movement coreBOS and similar projects have with respect to vtiger CRM or read the mailing list any month.... it is a mess.

(12-05-2016, 05:43 PM)jvidamins Wrote: 3. Not sure if you can help on this one, but I've never figured out how to accomplish this.  I have a contact record. As soon as I change the status of one of the fields of that record (Listing Status) to "Pending", I have a workflow that is set to run the "first time the condition is met" and will queue up several emails based on a date field in the record.  My problem is, sometimes the "Listing Status" field needs to be changed back to "Active" because the deal falls through.  Then, if a new deal comes along and I have to change it back to "Pending", the workflow doesn't run because it's already been met.  My solution for the past several years has been to duplicate the contact and delete the old one, so the workflow will run again.  There's got to be a better way!  Any suggestions?

This one should be easy to do. Using the task conditions you set the email to go out ONLY if the status is Pending, that way if you change it the currently programmed emails won't be sent (in case you want to avoid those emails). Then you change the condition of the workflow. Lanuch on every save, and set the condition to "Has Changed To Pending". So every time the record is saved and the piclist has changed to the value "Pending" the emails will be programmed.

Let me know how it goes.

Thanks for your trust in our work and I hope you enjoy all the enhancements we have implemented already and keep on implementing.

I look forward to seeing you around the community :-)

[jvidamins]

Looks like all the changes went through. I have 140 of them and they're all "executed" except for 3 are "pending" (the same ones that are pending on the demo site). But there's one that's "Pending": inventoryproductstockcontrol cbupd-0000051. When I run it again, it says "Changeset inventoryproductstockcontrol already applied!" Correct Updates: 1 Failed Updates: 0

But then it still says "Pending" when I go back into the main screen of the updater??

Also, the theme of my install is still the old vtiger 5.4 theme. How do I make it look like corebos?

Also, I did confirm that my already queued emails from vtiger 5.4 ARE in fact being emailed out under corebos!! That's great!

Lastly, I did the change you recommended for the workflow and they worked like a charm!!! Thank you so much!! I've applied the same principles to another workflow and it's working, too. Wish I would have converted a lot sooner!!!

---

Oh, and another thing I forgot to mention... I had some php errors in my error log:
PHP Notice: Undefined index: next_reminder_interval in /home7/jcbhomes/public_html/realtyparadigm/corebos/index.php on line 722

(had this one a lot) PHP Notice: Undefined index: next_reminder_time in /home7/jcbhomes/public_html/realtyparadigm/corebos/modules/Calendar/ActivityReminderCallbackAjax.php on line 21

PHP Notice: Undefined variable: VTIGER_BULK_SAVE_MODE in /home7/jcbhomes/public_html/realtyparadigm/corebos/cron/modules/Import/ScheduledImport.service on line 11

PHP Notice: Trying to get property of non-object in /home7/jcbhomes/public_html/realtyparadigm/corebos/modules/CronTasks/cronWatcher.service on line 70

Not sure what to make of them??

[joebordes]

For changeset 51, make sure you have a workflow to update stock associated with purchase orders. I reverted that changeset on my development install and applied it again and it worked correctly so I'm not sure why it is still pending on your install. Have a look and let me know. I will help you apply that one. This is the workflow you should have

http://corebos.org/demos/corebos/index.php?module=com_vtiger_workflow&action=editworkflow&workflow_id=14&return_url=index.php%3Fmodule%3Dcom_vtiger_workflow%26action%3Dworkflowlist%26parenttab%3DSettings

The theme is here:
https://github.com/Luke1982/mltheme-corebos

copy themes/MajorLabel into your themes directory and you should be able to select it in the user's profile

I think I fixed all those notice and warnings:

https://github.com/tsolucio/corebos/commit/e4559888b8f3d114f4ddfac5b7d163dd402efc41
https://github.com/tsolucio/corebos/commit/927edc37bc0f0d328f10fd8b8a3dbe0d789f3df7
https://github.com/tsolucio/corebos/commit/b05f95b525c930c95101233c2d08643fc71745d6

Thanks!

[jvidamins]

Well, I'm not sure what error log I was looking at when I posted the last 3, but I just looked at error_log located in the main corebos install folder, and it's 32 MB in size and has 188,343 PHP notices!!! I'm really freaked out! I don't even know where to start??? Should I delete them all, then just try pulling up a record and see what comes up? Is there a different way I need to be recording and looking at errors? Everything seems to be working, except every once in a while, I'll have a record load fail with an error, but I've been having that happen with my other sites, so I figured it was a server issue.

---

For changeset 51, I had the workflow, but there was no name for the Task, so I named it "Update Product Stock". Everything else was right. The update status still won't change from pending though. I tried to "Undo" the update, but it wouldn't let me. Do I delete it, then try to download and apply it again??

[jvidamins]

So for the url's of the things you fixed, I've never used git hub before. I'm assuming I'm just downloading the changed files and ftp/replacing them on my corebos install?

[joebordes]

For the notices. Configure your PHP to log only errors. In production servers I usually set error_reporting to E_ERROR, the wiki says something slightly different but in the same line. Locate your php.ini file, inside locate error_reporting and set it to E_ERROR

For the changeset, go directly to the database, look in the table vtiger_cbupdater for the record that belongs to changeset 51 and set the status to Executed.

Finally, you have to put your install under git control. We move to fast for you to control the changes manually. For example, since those three changes there has been 11 additional changes which completely change the graphs.

To work with git, you start by cloning the repository into your install directory. Instead of downloading as you did you install a git client for your operating system and launch:

git clone https://github.com/tsolucio/corebos

Then the workflow is:

- git pull
- fix any conflicts, which you shouldn't have unless you modify the files
- go to corebos updater, load and apply all changes (many times there won't be any)