* Fix: API addtimespent crashes with "Illegal offset type" on PHP 8+
Fixes#38407
The @param annotations for $date (datetime|string) and $progress (int|null)
in Tasks::addTimeSpent() use union types, which Restler's Validator parses
into a PHP array. Then Validator::validate() at line 427 evaluates
isset(static::$preFilters[$info->type]) using that array as an array key,
which throws "Illegal offset type in isset or empty" on PHP 8+. Every call
to POST /tasks/{id}/addtimespent therefore returns HTTP 500 before the
endpoint code runs.
Use single-type annotations matching the convention already used by
Tasks::putTimeSpent in the same file: @param datetime + @phan-param string
for the date, and plain @param int for progress (its -1 default already
encodes "leave unchanged", so int|null is not needed).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Vincent Moreno <vincent.moreno@hupi.fr>
* Update parameter type for date in API documentation
* Update api_tasks.class.php
---------
Signed-off-by: Vincent Moreno <vincent.moreno@hupi.fr>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: Laurent Destailleur <eldy@destailleur.fr>
- Fixed false positive error logging in `_recordActionResult`: an `update()` returning 0 (no rows affected) is no longer treated as an error (changed `<= 0` to `< 0`).
- Fixed `birth` date data type for Adherent anonymization: replaced the static string '1900-01-01' with a UNIX timestamp using `dol_mktime()` to comply with Dolibarr Core standards and prevent silent DAL failures.
OIDC was converted from a module to a config-level feature in v23 (#36051),
renaming the enable constant. No migration was added to update existing
llx_const rows, causing OIDC to appear disabled after a v22 -> v23 upgrade.
Add an inline edit pencil next to 'QtyToProduce' on the MO card and the
MO production view when the order is still in DRAFT status. On save:
1. The MO qty is updated through Mo::update(), which internally calls
Mo::updateProduction() to scale 'toconsume'/'toproduce' lines
proportionally (newQty/oldQty), respecting qty_frozen flags.
2. The 'toproduce' line for the MO's main product is then explicitly
realigned to match the MO qty exactly. This guards against legacy
inconsistent states and floating-point drift from successive ratio
scaling, while leaving BOM sub-product ratios and frozen lines
untouched.
The handler is placed BEFORE the include of
actions_addupdatedelete.inc.php, because that file has a generic
'set<key>' matcher that would otherwise intercept 'setqty', call
$object->fetch() + update() without setting $object->oldQty, and
silently skip the line scaling.
The edit is gated both client-side (pencil only shown when DRAFT) and
server-side (setqty handler checks STATUS_DRAFT) to prevent any
modification once the MO has been validated.
Note: the field type 'real' is temporarily overridden to 'numeric' only
while the edit pencil is active (action=editqty), because
Form::editfieldval() in html.form.class.php does not handle 'real' and
would render the Save/Cancel buttons with no <input> field in between.
Read-mode rendering (via price()) is preserved.
* Fix: avoid undefined method stdClass::isEmpty() on PHP 8.1
This fixes a fatal error when updating product prices on PHP 8.1 due to stdClass object handling.
* Update ProductCombination.class.php
---------
Co-authored-by: Laurent Destailleur <eldy@destailleur.fr>
* FIX#37356 Category Products not listed
* Will now show product and service categories when 1 or both modules for products or services are enabled #38264
---------
Co-authored-by: Jon Bendtsen <jonbendtsen@jonb.dk>
* Fix#38278 POST to API /members/{id}/subscriptions returns -1
* return the id of the new subscription
---------
Co-authored-by: Jon Bendtsen <jonbendtsen@jonb.dk>
The empty option in the supplier/customer general account dropdown gets
value='-1' from Form::selectarray. When the form is submitted, GETPOST
returns '-1' and Societe::create()/update() stores it as a string because
the SQL builder's !empty() check accepts '-1' as truthy.
The bookkeeping export in purchasesjournal.php and sellsjournal.php then
uses '-1' as the account code (only bankjournal.php has a != '-1' guard)
and the transfer fails.
Normalize '-1' to '' next to the existing trim() in create() and update()
for both accountancy_code_customer_general and accountancy_code_supplier_general.
The existing SQL !empty() checks then write NULL as intended, and rows
that already contain '-1' self-heal on the next update.
