Few days ago is gone out the 8.3.1 version
I have the 8.3 version, and now what should I do to upgrade suitecrm from 8.3to 8.3.1 ?
Here Upgrading :: SuiteCRM Documentation
It says only that to upgrade to 8.3.1 I firstly need 8.3 and I have 8.3.0 but how to upgrade to 8.3.1 ?
I tryed with module package, but it says that the package is wrong. but the zip file works well in my chromebook…
I completed v8.3 to V8.3.1 tonight successfully. This is on a test server with ubuntu 20.04LTS, php8.0 and Mariadb 10. my apache owner is www-data so check your installation.
my SuiteCRM “root” folder is /var/www/html/Suitecrm and I created:
/var/www/html/Suitecrm/public/tmp/package/upgrade directory and copied the SuiteCRM-8.3.1.zip file to that directory.
I ran the instruction (without the .zip) from the “root” directory
./bin/console suitecrm:app:upgrade-finalize -t "SuiteCRM-8.3.1"
which performed the upgrade. Then I followed with:
suitecrm:app:upgrade-finalize
I restarted apache and it works. I made sure I had a server backup of v8.3 in case something went wrong. I’m using a test server on Linode for about $5/month and it works quite well for testing.
Worked perfectly. Thanks!
Same procedure for v8.4.0-beta and you will have to check directory permissions and ownerships. Suitecrm is not self-aware of its installation environment and you don’t have the option to set those variables (yet).
In the procedure, are we really supposed to be calling upgrade-finalize twice?
Just found an issue with SMTP.
Did your smtp work after the upgrade? After the upgrade our smtp authentication stopped working correctly.
Thanks
-Ed
@pgr, you are correct, the “finalize” option was not done on the first pass. I tried to fix the original post but can’t see any way to edit. Thanks. It should be:
I ran the instruction (without the .zip) from the suitecrm “root” directory
./bin/console suitecrm:app:upgrade -t "SuiteCRM-8.3.1"
which performed the upgrade. Then I followed with:
suitecrm:app:upgrade-finalize
I found that the IDs stored for emails had tons of old references from previous testing and upgrades. I cleaned those out and re-loaded the server details and it worked fine. In the upgrade to v8.31 and now v8.4 I found the dashlet for email stopped providing SUBJECT. See attachment. I fixed it using this topic. The dashlet for MyTasks also does not work still in v8.4 for me. The software is still creating cache and other directories with the wrong user. There is no reason not to load a configuration with the proper owner and attributes for your server www-data or whatever. It is kind of dumb to have the user do admin work just for updating the software and find the directories and permissions are mismatched. This should be high priority and no other software requires this type of admin fixes for install or updates (that I use).
You still don’t have your ownerships/permissions set correctly.
Things you need to pay attention to:
default_permissions entry in config.php
Here’s a detailed write-up:
This is v8.4 demo. I dispute your assessment that permissions are not set properly. A million users should not each have to set a million sets of permissions. It is the software that should do that. It is insane to tell novice users to become admins for a server. It isn’t a reasonable position to take.
SuiteCRM is not a common application. It is an application that writes itself. It produces PHP code. Some of the reasonable assumptions people make for applications, are not sufficient for SuiteCRM.
SuiteCRM software cannot possibly do anything about operating system level permissions, if they are too tight. It cannot change permissions (to avoid you doing the work of a sysadmin) if you started it running in an environment that does not allow that. This is actually the most common scenario in shared hostings.
That said, there are bugs, there is confusing documentation, there is the unnecessarily difficult diagnosis of problems. I know it can be frustrating.
SuiteCRM is not making up that wrong user - as I wrote, it is either in your default_permissions settings, or it is the user you set up your cron jobs with. It can also be some user that you logged in as, and left directories owned by that user (ownership of new files that are created is derived from the parent directory).
Note that I only set permissions once, not a million times, for every system I set up. I recognize that this requires doing things precisely right in a way that might not obvious for new users. And it’s really hard to create precise instructions when the scenarios are so diverse (Windows, Mac, all sorts of Linuxes, self-hosted, shared, auto-installed, command-line-installed, pulled from Git, dockerized, VMs, etc). But I just want you to know that it is possible.
