* FIX#32909 Restrict salary/HR field edit to authorized users
On the user card, a user with only "modify own info" (user->self->write)
could edit thm, tjm, salary, salaryextra and weeklyhours, even though the
display of these fields is gated on salaries->readall / hrm->employee->read.
Guard the write of these fields with the same permission used for display,
so self-service users can no longer change compensation data they are not
allowed to see.
Signed-off-by: Sanjiv Kumar Bhagat <reach.sanjiv.bhagat@gmail.com>
* Update card.php
* Update salary edit permissions logic
---------
Signed-off-by: Sanjiv Kumar Bhagat <reach.sanjiv.bhagat@gmail.com>
Co-authored-by: Laurent Destailleur <eldy@destailleur.fr>
* Fix: mass createbills success message showed draft PROV ref instead of final ref
Extended description (corps de la PR)
When creating an invoice from several orders at once via the order list
mass action ("Create invoice for this customer"), with the "Validate
generated invoices" option set to "yes", the success message and its link
displayed the temporary draft reference (PROVxxxx) instead of the final
validated invoice reference.
Root cause:
In htdocs/commande/list.php, during the confirm_createbills action, $lastref
is captured right after $objecttmp->create($user), at which point the invoice
is still a draft (PROVxxxx). When the "validate invoices" option is enabled,
each invoice is then validated through $objecttmp->validate($user), which
assigns the definitive reference to the object. However $lastref was never
refreshed afterwards, so the "BillXCreated" message (single-invoice case) kept
showing the draft ref.
Fix:
Refresh $lastref from the object inside the validation loop, after a successful
validate(), so the success message links to and displays the final reference.
Only the single-invoice success message exposes a reference, so this is the only
case affected; the multi-invoice message only shows a counter.
Steps to reproduce:
1. Go to the orders list.
2. Select several orders (or one), and choose the "Create invoice for this
customer" mass action.
3. Set "Validate generated invoices" to "Yes".
4. Confirm.
=> Before: the success message links to the draft ref PROVxxxx.
=> After: the success message links to the final validated invoice ref.
* Fix indent
* Delete linked categories on proposals and invoices
Ensure category links are removed when deleting proposals, supplier proposals and supplier invoices by adding DELETE queries for categorie_propal, categorie_supplier_proposal and categorie_supplier_invoice and handling DB errors. Reorganize supplier invoice delete logic so category cleanup occurs before discount freeing. Update PHPUnit tests (PropalTest, SupplierProposalTest, FactureFournisseurTest) to create a category link, assert deletion of the category row after object delete, and require the categorie class.
* Update FactureFournisseurTest.php
* Always delete linked supplier invoice categories
Remove the surrounding if(!$error) guard so the DELETE from categorie_supplier_invoice runs regardless of prior errors. This ensures linked categories are always cleaned up for the supplier invoice; preserved existing error handling to record DB failures.
* Update PropalTest.php
* Update SupplierProposalTest.php
* Fix#34774 accept YYYYMMDDHHMMSS datep param sent by /societe/agenda.php
htdocs/societe/agenda.php:195 builds the AddAction button URL with
&datep=...dol_print_date(dol_now(), 'dayhourlog')... which expands to
14 digits (YYYYMMDDHHMMSS). htdocs/comm/action/card.php:104 only accepts
the 8-digit YYYYMMDD variant, so the regex misses, $datep stays null
and the date/time pre-fill on the form fails.
Add a leading regex branch that decodes the dayhourlog form and falls
through to the existing 8-digit handler for legacy callers.
Signed-off-by: Dolicraft <contact@dolicraft.com>
* Fix#34774 follow-up: producer-side emit &datep=now per eldy review
PR #38792 was the consumer-side fix (accept 14-digit datep in comm/action/card.php).
Eldy pointed out the cleaner fix is producer-side: send the documented
&datep=now form that the consumer comment at line 104 already recommends
('Try to not use this. Use instead datep=now'). Apply that on the
AddAction URL in /societe/agenda.php.
Kept the consumer-side 14-digit fallback from the previous commit so any
other caller still emitting the old YmdHis form keeps working until they
are migrated too.
Signed-off-by: Dolicraft <contact@dolicraft.com>
* Fix#34774 CI: cast $search_filtert to string for urlencode (phpstan)
Signed-off-by: Dolicraft <contact@dolicraft.com>
---------
Signed-off-by: Dolicraft <contact@dolicraft.com>
Co-authored-by: Dolicraft <contact@dolicraft.com>
Webklex/PHPIMAP getFolders() in pattern mode treats the second argument
as a sourcedir* glob, so INBOX returns INBOX plus every INBOX.* subfolder.
The collector then took $f[0], which is whichever folder the IMAP server
returned first - often an empty 'INBOX.Traites' archive - so the polling
silently scanned the wrong mailbox and reported no new mail while messages
piled up in INBOX.
Walk the returned list once and prefer the folder whose full_name matches
$tmpsourcedir exactly. Fallback to $f[0] preserves the previous behavior
when no exact match exists (e.g. server-side capitalization quirks).
Signed-off-by: Dolicraft <contact@dolicraft.com>
Co-authored-by: Dolicraft <contact@dolicraft.com>
SUBTOTALS_SPECIAL_CODE is only defined by the subtotals module
(htdocs/subtotals/class/commonsubtotal.class.php:24). When a PO line
is printed into a vendor invoice create screen and the subtotals module
is not loaded for the current request, htdocs/core/class/commonobject.class.php
line 5872 fatals with 'Undefined constant SUBTOTALS_SPECIAL_CODE',
hiding every origin line.
Wrap the comparison with defined() to match the existing pattern used in
objectline_view.tpl.php:81, objectline_edit.tpl.php:71 and
originproductline.tpl.php:50.
Signed-off-by: Dolicraft <contact@dolicraft.com>
Co-authored-by: Dolicraft <contact@dolicraft.com>
htdocs/core/class/html.formcompany.class.php:339,341,347 picks
$langs->trans($obj->code) for the province dropdown, where $obj->code
is the c_departements code. For Italy that includes IM = Imperia. The
en_US main.lang key 'IM=Instant messaging' was used as fallback and
shadowed the province label.
Rename the lang key to InstantMessaging. No PHP caller references the
old key (grep finds only the .lang files themselves), so this rename
breaks no flow today. Non-en_US locales will resync through Transifex.
Signed-off-by: Dolicraft <contact@dolicraft.com>
Co-authored-by: Dolicraft <contact@dolicraft.com>
The API discovery loop in htdocs/api/index.php (around line 308) accepts
both Foo and FooApi class names when scanning module directories. The
dispatch loop on the request-handling side (line 422) only checked
class_exists($classname), so a module exposing class MyModuleApi from
api_mymodule.class.php would appear in the API Explorer yet 501 with
'API not found' when the endpoint was actually called.
Probe class_exists($classname.'Api') first to mirror the discovery
behavior. Falls back to the plain class name so existing modules keep
working.
Signed-off-by: Dolicraft <contact@dolicraft.com>
Co-authored-by: Dolicraft <contact@dolicraft.com>
