Closed kingswindsor closed 1 year ago
There appears to be an incompatibility between Grocy Mobile (Grocy-SwiftUI) and Grocy v3.3.2 [...] with the removal of the qu_factor_purchase_to_stock field
Just to clarify that also here: v3.3.2 has not (!) removed this field, so this can't be the problem when running the current Grocy release v3.3.2.
@kingswindsor is most likely running the current development version (see https://github.com/grocy/grocy/issues/2240#issuecomment-1556293526) and also uses an unsupported PHP runtime version, so naturally everything can go wrong without real surprise I guess.
Yeah, this is definitely an incompatibility. The App sends the field _qu_factor_purchase_tostock, but it is not in the database (anymore). For this, a compatibility check is integrated in the App and warns the user if an incompatible version is used. Until the next big update (Grocy 4.x ?) is released, the App will not be updated to reflect this behavior, since tracking non-release versions is too much a hassle.
Thanks @supergeorg Yes, waiting for the next main release is a good idea rather than chasing development releases. Just an observation though on the compatibility checker in your App - following on from my conversation with @berrnd referred to above, I've been checking out the Grocy versions to to find the one that works with your app.
I've attached screenshots from your app with both branches, and both have the green tick for compatibility. @berrnd is using the master branch for development and this seems to have introduced incompatibility with the deletion of the qu_factor_purchase_to_stock field. Maybe the compatibility checker needs to check for the v3.3.2 release branch and not just v3.3.2 (assuming that is what it does)?
In the pics below, the instance with v3.3.2 master is the one with PHP v 8.2.6 and v3.3.2 release has PHP 8.0.28. (By the way, PHP 8.2.6 seems to work fine despite Grocy only officially supporting PHP 8.0 (but v3.3.2 master branch requires PHP8.1.0 to run Apache2)).
Ok, this seems strange. The prerelease demo server has prerelease in its version number.
{
"grocy_version": {
"Version": "pre-release-8c033ff6",
"ReleaseDate": "2023-05-23 21:26:53"
},
"php_version": "8.1.18",
"sqlite_version": "3.34.1",
"os": "Linux 5.15.107-1-pve #1 SMP PVE 5.15.107-1 (2023-04-20T10:05Z) x86_64",
"client": "Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.5 Mobile/15E148 Safari/604.1"
}
A date check (that no time is shown) would be a good filter. But the latest commit as version is the expected behaviour.
Ok, this seems strange.
Trying to shed some light into the mysterious darkness:
When MODE
is production
(default), demo
or dev
, the version information is just taken from version.json
.
When MODE
is prerelease
, the version is pre-release-<head commit hash>
and the release date is the timestamp of that same commit (code ref for all that).
MODE
is set to demo
for the current release / stable demo and to prerelease
for the pre-release demo, I can't say and have no control over how that is set on any personal instance (it defaults to production
).
The master
branch in "production" should only be used by those who really know what they do and by those who can handle everything needed for that (especially database migrations, README ref). I personally even use always the latest release for my personal Grocy instance, not the current development state.
See https://github.com/grocy/grocy/issues/2240
There appears to be an incompatibility between Grocy Mobile (Grocy-SwiftUI) and Grocy v3.3.2 and likely also later releases with the removal of the qu_factor_purchase_to_stock field.