* 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.
The validator notification email warned about insufficient balance regardless
of whether the leave type has affect=1 in c_holiday_types. For types like
overtime compensation or unpaid leave (affect=0), getCPforUser() always
returns 0 and the warning fires on every request.
Same getTypes(1, 1) filter that the balance display in the form uses.
For credit notes, getRemainToPay() returns a negative value. The previous
condition ($remaintopay > 0) skipped payment creation entirely, leaving the
credit note in an unpaid/open state after TakePos validation.
* FIX: propagate fk_warehouse from BOM line in processBOM()
When creating MO lines from a BOM, the fk_warehouse defined on each
BOM line was not copied to the corresponding MO line. This caused
produceandconsumeall() to fail with a stock movement error when a
warehouse is set on BOM lines but not on the MO itself.
* FIX: propagate fk_warehouse from BOM line in processBOM()
When creating MO lines from a BOM, the fk_warehouse defined on each
BOM line was not copied to the corresponding MO line. This caused
produceandconsumeall() to fail with a stock movement error when a
warehouse is set on BOM lines but not on the MO itself.
* Update mo.class.php
---------
Co-authored-by: Laurent Destailleur <eldy@destailleur.fr>
In FormFile::list_of_documents(), when the user clicks the "+ New" button to reveal the upload form (showhideaddbutton), the JS handler triggers jQuery("input[type='file']").click(). This selector matches every <input type="file"> on the page, opening the OS file picker once per match. Users with multiple file inputs in the DOM (e.g. another hidden upload form, an editor's media browser, modules with their own attachers) have to dismiss the file dialog several times before being able to drag-drop or browse normally.
Fix: scope the selector to the form that was just shown:
- jQuery("input[type='file']").click();
+ jQuery(".divattachnewfile input[type='file']").first().click();
No regression on pages with a single .divattachnewfile. Reproduces on any *document.php tab where a hidden second <input type="file"> is present.
When a product has no row in llx_product_price (typical for products
imported in bulk where only llx_product was populated), price.php
auto-creates an initial history line on first display of the price tab
(branch starting at "We must have at least one initial line").
The two updatePrice() calls in this branch omitted parameter 11
(\$newdefaultvatcode) which defaults to ''. In Product::updatePrice()
the SQL then writes default_vat_code = NULL in BOTH llx_product and
the new llx_product_price row, silently wiping a correctly-stored VAT
code on every first display.
Symptom: "ErrorBadValueForParamNotAString" rendered next to selling
price/min selling price (because \$langs->trans(\$object->price_base_type)
is called with NULL when the row is freshly created with empty fields),
and default_vat_code persistently reset to NULL until the user manually
re-saves through the form.
Fix: forward \$object->default_vat_code (and \$object->tva_npr for the
non-multiprice branch) to updatePrice() so the auto-init preserves the
product's VAT configuration.
