8530Cloud
New Member
Hello Clientexec team,
During configuration and testing of our Clientexec environment at 8530Cloud, we identified a reproducible issue with decimal separators in product pricing fields.
We have been able to reproduce the issue and recover the affected products through MariaDB.
Environment
Clientexec accepts prices entered with a comma as the decimal separator, for example:
49,95
The value can be saved without a validation warning. However, after saving it, parts of the product configuration can stop loading correctly.
Entering the same value using a decimal point works correctly:
49.95
Steps to reproduce
Event Log
Clientexec reported errors including:
PackageGateway.php line 532: round(): Argument #1 ($num) must be of type int|float, string given
We also encountered:
Prices.php line 80: Call to a member function getType() on bool
Database investigation and recovery
We investigated the affected records in MariaDB and found the malformed monetary values in the prices table.
We were able to recover the affected products by correcting the stored values from comma notation to decimal-point notation, for example:
8,99 → 8.99
After correcting the affected values, the Clientexec product configuration became accessible again.
An important detail is that products can contain multiple price records for different billing cycles and fields. Correcting one value was therefore not necessarily sufficient. During recovery, affected price values had to be corrected individually.
Expected behaviour
We believe Clientexec should prevent an invalid decimal representation from reaching a state where the product configuration becomes inaccessible.
Ideally, Clientexec could either:
Automatic normalization may be particularly useful for European administrators, where a comma is commonly used as the decimal separator.
A simple input validation/normalization check would prevent an accidental formatting mistake from requiring database-level recovery.
We can provide screenshots and additional information from our test environment if required.
Kind regards,
8530Cloud
During configuration and testing of our Clientexec environment at 8530Cloud, we identified a reproducible issue with decimal separators in product pricing fields.
We have been able to reproduce the issue and recover the affected products through MariaDB.
Environment
- Clientexec: 7.2.1
- Currency: EUR
- Database: MariaDB
- Affected area: Product configuration / Pricing
Clientexec accepts prices entered with a comma as the decimal separator, for example:
49,95
The value can be saved without a validation warning. However, after saving it, parts of the product configuration can stop loading correctly.
Entering the same value using a decimal point works correctly:
49.95
Steps to reproduce
- Open an existing product in the Clientexec admin area.
- Go to the product Pricing configuration.
- Enter a valid price using a decimal point, for example 49.95, and save it.
- Confirm that the product configuration continues to work.
- Change the same price to 49,95.
- Save the product.
- Reopen the product configuration.
In our testing, the product administration interface then failed to render parts of the General, Pricing and Upgrade/Downgrade configuration correctly.
Event Log
Clientexec reported errors including:
PackageGateway.php line 532: round(): Argument #1 ($num) must be of type int|float, string given
We also encountered:
Prices.php line 80: Call to a member function getType() on bool
Database investigation and recovery
We investigated the affected records in MariaDB and found the malformed monetary values in the prices table.
We were able to recover the affected products by correcting the stored values from comma notation to decimal-point notation, for example:
8,99 → 8.99
After correcting the affected values, the Clientexec product configuration became accessible again.
An important detail is that products can contain multiple price records for different billing cycles and fields. Correcting one value was therefore not necessarily sufficient. During recovery, affected price values had to be corrected individually.
Expected behaviour
We believe Clientexec should prevent an invalid decimal representation from reaching a state where the product configuration becomes inaccessible.
Ideally, Clientexec could either:
- automatically normalize 49,95 to 49.95; or
- reject the value before saving and display a clear validation message, such as:
Automatic normalization may be particularly useful for European administrators, where a comma is commonly used as the decimal separator.
A simple input validation/normalization check would prevent an accidental formatting mistake from requiring database-level recovery.
We can provide screenshots and additional information from our test environment if required.
Kind regards,
8530Cloud
