search

supergeorg / Grocy-SwiftUI

A client for Grocy for macOS and iOS, written with SwiftUI
GNU General Public License v3.0
177 stars 17 forks source link

Add on apps (Pantry Party and Grocy Mobile (IOS app)) both fail with same error when attempting to add product to database when using bar code scanning. #164

Closed kingswindsor closed 1 year ago

kingswindsor commented 1 year ago

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.

berrnd commented 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.

supergeorg commented 1 year ago

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.

kingswindsor commented 1 year ago

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)). InkedIMG_1588 InkedIMG_1590

supergeorg commented 1 year ago

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.

berrnd commented 1 year ago

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.