When refreshing an expired OAuth2 access token (XOAUTH2 auth mode),
the default HTTP client used by \OAuth\ServiceFactory may not work
in environments where stream-based HTTP calls are restricted (e.g.
Docker containers with allow_url_fopen disabled or limited outbound
stream access).
Explicitly set CurlClient as the HTTP client for the ServiceFactory
in both the SMTPS and SwiftMailer send paths so that token refresh
requests reliably use cURL, which is available and functional in
standard PHP environments.
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Laurent Destailleur <eldy@destailleur.fr>
When MEMBER_NEWFORM_FORCECOUNTRYCODE is set to a country code string (e.g. 'ET'),
getDolGlobalInt() converts it to 0 and silently ignores the fallback GETPOSTINT('country_id'),
causing a "Country is required" validation error even though the constant is defined.
Also fix the view section which used getCountry() mode '2' (returns ISO code string)
instead of mode '3' (returns rowid integer), making select_country() unable to pre-select
the forced country.
Both cases now use getCountry(..., '3', ...) which correctly resolves both ISO codes
and numeric IDs to a rowid.
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
When cloning an invoice from one entity to another via the multicompany
entity selector, the cloned invoice was always created in the source entity.
The multicompany module correctly displays an entity selector in the clone
confirmation dialog (formConfirm hook), but the core handler for
'confirm_clone' in card.php never read the posted 'entity' parameter.
Additionally, Facture::createFromClone() had no 'forceentity' parameter,
unlike Propal::createFromClone() which already handled this correctly.
Fix:
- Add $forceentity = null parameter to Facture::createFromClone()
- Apply forceentity to the cloned object after fetch, before create()
- Pass GETPOST('entity') from card.php confirm_clone handler to createFromClone()
# FIX#36258: Do not format qty from barcode
When a barcode contains a quantity (e.g., 0.275 from qu=0 and qd=275),
the quantity is already in international format (using '.' as decimal separator).
However, when this qty is passed to invoice.php, it uses GETPOSTFLOAT('qty')
which defaults to option=2, meaning it treats the value as local user format.
In Spanish/Argentinian locale (thousand separator=., decimal separator=,),
price2num with option=2 incorrectly treats 0.275 as a number with thousand separator
and converts it to 275.
## Solution:
1. Add a 'qty_std' parameter to the URL when calling invoice.php from barcode
2. In invoice.php, use GETPOSTFLOAT('qty', '', 1) when qty_std is set
3. Option=1 tells price2num that the value is NOT in local user format
This way, qty from barcode (already in international format) is not converted,
while qty from user input (in local format) continues to be converted correctly.
Changes:
- htdocs/takepos/index.php: Add qty_std parameter to ClickProduct and pass it through to invoice.php
- htdocs/takepos/invoice.php: Use GETPOSTFLOAT with option=1 when qty_std is set
Co-authored-by: Laurent Destailleur <eldy@destailleur.fr>
