So far so good. We only ran into the following issues:
/platform/security/settings – ROLES & PERMISSIONS were not migrated correctly. All roles ended up set to Administrator.
Some specific JDBC drivers were not migrated properly, for example the Denodo JDBC Drivers. This caused the error: java.sql.SQLException: Cannot create PoolableConnectionFactory (isValid() returned false)
The MySQL driver is marked as unhealthy, which is odd since it comes bundled with Ignition — though we don’t actually use it.
TTS Voice - es_sara was not migrated correctly.
com.inductiveautomation.ignition.common.modules.ModuleLoadException: Module "TTS Voice - es_sara" requires Ignition 8.0.0 (b0) and is not compatible with Ignition 8.3.0 (b2025091510)
The license migration was tricky yesterday, but after testing with another license today it seems to be resolved.
I was reading the migration guide last night and maybe I'm not remembering correctly, but I thought this was a known thing that gateway security is reset and not migrated, unless it's a different part it was talking about.
Edit: maybe not the same thing
8.3 Gateway webpages now operate on a required role basis. Certain pages and actions will not be available if a user is not signed in, or does not have the correct roles or permissions. Additionally, permissions granted in 8.1 will not automatically roll over into 8.3, and must be reassigned.
This might sound a bit odd – but could you try editing the MySQL JDBC Driver and edit something trivial – like adding a space or character to the URL Instructionsand see if that pops the MySQL connection back to healthy? I was chasing an odd Cannot load JDBC driver class 'com.mysql.jdbc.Driver error after upgrade that I haven’t recreated and re-saving the JDBC Driver “fixed” it at the time.
Is there a way to check the database logs to see if there is any indication on what is going on? There are multiple things that could be problematic and we are going to have to try and narrow it down. Some of the possibilities:
The JDBC driver didn't get migrated properly: This probably isn't the case, but it should exist in the <ignition root>/data/config/resources/core/ignition/database-driver/<driver name> directory.
The JDBC driver could be incompatible with the version of JAVA included with Ignition: This is unlikely, as both 8.1 and 8.3 are using Java 17, but if you are coming from an older version of Ignition 8.1 it is something to consider.
The settings themselves are not migrating completely: It might be worth trying to configure the connection as you would expect it to work in 8.3 and see if the behavior changes. If you do this, having a before and after of the <ignition root>/data/config/resources/core/ignition/database-connection/<connection name>/config.json would be beneficial. Especially if it fixes things
There is a known issue where if a password is not set, the username isn't provided when attempting a connection. If your connection does not require a password, set the Password field to Embedded and leave it blank.
This is to be expected. Due to licensing issues with including JDBC drivers with the application, the MySQL and Oracle modules will be flagged as UNHEALTHY because they are not complete. We include everything else needed for a connection to be defined. It isn't something we find ideal, it gets flagged with global validation checks
There are new modules for voices that are compiled for 8.3 that can be downloaded from here.
Thanks for the screenshot – I’m afraid I’m going to ask more questions as I’m able to upgrade with custom roles on my side so far so I’m guessing I’m missing a pre-upgrade config difference to recreate.
Just to make sure I’m on the right page:
It sounds like you upgraded from 8.1.49 (8.1 latest?).
You are referring to the Roles & Permissions on the General Settings page under Security (assuming that’s what you meant by /platform/security/settings - the url path) – ex. Gateway Write/Read/Access Permissions
From the screenshot, you have a custom security level of “Management” with at least 3 roles under that, including Administrators.
All the roles on the General Security page were incorrectly set to only Administrators?
Was the Administrators level still listed under Management or under the Roles level?
Is your Designer Authentication Mode set to Classic or IdP? Did those migrate correctly?
Was Create Project Perm set to a non-Public user and then assigned Administrator after the migration?
Do you feel comfortable sharing your Identity Provider type? Internal, OpenID, SAML?
Do you feel comfortable sharing your user source type?
In the wrapper.log, do you have any errors in the section that starts logging messages from MigrationLog? Regular logging might look like
I [c.i.i.g.c.m.MigrationLog ] [11:29:50.826]: Migrated table(s) [SECURITY_LEVELS] in 57ms
I [c.i.i.g.c.m.MigrationLog ] [11:29:51.065]: Migrated table(s) [securityZones, SecuredEntityPolicy, SecuredEntityZonePolicy] in 23ms
I requested the logs and will provide an update once I have more information. I also tested changing the password, and the error now shows as “incorrect password,” so it’s definitely not related to the driver. I’m using the latest version, which worked fine in 8.1.48. I even overwrote the driver, but without success.
I am not sure but probably. What I am sure is that “Developers“ which where allowed to see logs in 8.1, in 8.3 they could not see the logs but where authorized to login into the gateway.
Thank you for answering my many questions, it was very helpful!
Reviewing this detail -- "Developers" which where allowed to see logs in 8.1, in 8.3 they could not see the logs but where authorized to login into the gateway. -- I wonder if in 8.1, Administrators and Developers were assigned to Status Page Permissions? With Administrators assigned to Gateway Config Permissions?
If this was the case, then after the upgrade, Administrators would be assigned to the new Gateway Write and Read Permissions. Due to the new webUI layout, the Status Page Permissions setting is no longer in 8.3 and you would not see the Developers level selected in the Roles & Permissions. Home Page Permissions migrated to Gateway Access Permissions and if this perm was left as its default setting of Public, you would be able to log into the Gateway with a Developers user, but be limited to seeing the Home section of the WebUI.
In this case, you could consider setting Developers to the Gateway Read Permissions setting to allow them to view the logs, but the Read permission gives read access to the general WebUI which would include configuration information, giving them different access than in 8.1.
Yes, that’s the new scenario now. Personally, I don’t see an issue with developers having visibility into the configuration, but others might feel differently.
