(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?