Fix the following error when running without the dataset.
Fichinter
✘ Fichinter create
┐
├ ERROR: 23503: insert or update on table "llx_fichinter" violates foreign key constraint "fk_fichinter_fk_soc"
├ DETAIL: Key (fk_soc)=(1) is not present in table "llx_societe".
├ SCHEMA NAME: public
├ TABLE NAME: llx_fichinter
├ CONSTRAINT NAME: fk_fichinter_fk_soc
├ LOCATION: ri_ReportViolation, ri_triggers.c:2596,
├ Failed asserting that 0 is less than -1.
│
│ dolibarr/test/phpunit/FichinterTest.php:147
┴
Adding $localobject->errorsToString() as third argument to the assert
will allow to forward internal errors towards the tests and display them
accordingly.
The testContratCreate() is using the default value for Contrat::socid,
which is defined by Contrat::initAsSpecimen to `0`. But if no companies
have been created, the test will fail with the following error:
Failed asserting that 0 is less than -1.
Or with the additional logging:
UnknownError: ERROR: 23503: insert or update on table "llx_contrat" violates foreign key constraint "fk_contrat_fk_soc"
DETAIL: Key (fk_soc)=(1) is not present in table "llx_societe".
SCHEMA NAME: public
TABLE NAME: llx_contrat
CONSTRAINT NAME: fk_contrat_fk_soc
LOCATION: ri_ReportViolation, ri_triggers.c:2596 -,
Failed asserting that 0 is less than -1.
The test doesn't really depends on specific test data so we can create
the company directly instead.
The testCompanyBankAccountCreate() is using the default value for
CompanyBankAccount::socid, which is defined by
CompanyBankAccount::initAsSpecimen to `0`. But if no companies have been
created, the test will fail with the following error:
Failed asserting that 0 is less than -1.
Or with the additional logging:
ERROR: 23503: insert or update on table "llx_societe_rib" violates foreign key constraint "llx_societe_rib_fk_societe"
DETAIL: Key (fk_soc)=(1) is not present in table "llx_societe".
SCHEMA NAME: public
TABLE NAME: llx_societe_rib
CONSTRAINT NAME: llx_societe_rib_fk_societe
LOCATION: ri_ReportViolation, ri_triggers.c:2596, ERROR: 23503: insert or update on table "llx_societe_rib" violates foreign key constraint "llx_societe_rib_fk_societe"
DETAIL: Key (fk_soc)=(1) is not present in table "llx_societe".
SCHEMA NAME: public
TABLE NAME: llx_societe_rib
CONSTRAINT NAME: llx_societe_rib_fk_societe
LOCATION: ri_ReportViolation, ri_triggers.c:2596
Failed asserting that 0 is less than -1.
The test doesn't really depends on specific test data so we can create
the company directly instead.
The testCommandeCreate() is using the default value for Commande::socid,
which is defined by Command::initAsSpecimen to `0`. But if no companies
have been created, the test will fail with the following error:
Failed asserting that 0 is less than -1.
Or with the additional logging:
ERROR: 23503: insert or update on table "llx_commande" violates foreign key constraint "fk_commande_fk_soc"
DETAIL: Key (fk_soc)=(1) is not present in table "llx_societe".
SCHEMA NAME: public
TABLE NAME: llx_commande
CONSTRAINT NAME: fk_commande_fk_soc
LOCATION: ri_ReportViolation, ri_triggers.c:2596,
Failed asserting that 0 is less than -1.
The test doesn't really depends on specific test data so we can create
the company directly instead.
* societe: add missing model_pdf field
The field is used by the class but wasn't declared.
* societe: expose Societe::mergeCompany
The code is directly copied from societe/card.php with as less changes
as possible.
The original code came from deb91ad7c1.
* societe: remove fields from property copy
$phone_pro and $fk_project are not existing for societe. This was added
from deb91ad7c1.
* SocieteTest: test the merge functionality
This test is a simple smoke test to check that the mergeCompany() will
work correctly on simple case and actually merge the details of the
company.
More complex deduplication pattern with objects referencing the deleted
Societe object, will be written for each of the different object class
in their respective test file.
* societe: card: use the new mergeCompany function
Since the code is almost the same, there should be no differences in
behaviour right now.
* societe: api_thirdparties: use Societe::mergeCompany()
* societe: fix issue when merging companies
When a Societe object is merged against another, its related objects are
supposed to reference the new Societe object so that the databse doesn't
raise foreign key errors.
The list references the objects that need to be transformed, and
Reception objects weren't part of this list.
Fix#26272
* ReceptionTest: check company merge hook
Before a Societe object is destroyed from the database, every object
referencing the FK should be destroyed or should reference another
object.
In the case of two companies being merged, the case arises and Reception
objects need to be moved to the new company. This commit brings a
non-regression test for this case.
Refs #26272
* Update societe.class.php
---------
Co-authored-by: Laurent Destailleur <eldy@destailleur.fr>
* reception: reOpen: mirror $this->statut in $this->status
$this->statut is the deprecated variable, $this->status should also get
the correct value.
* reception: setDraft: mirror $this->statut in $this->status
$this->statut is the deprecated variable, $this->status should also get
the correct value.
* reception: add missing $weight field
Fix warning:
Undefined property: Reception::$weight
* societe: add country_id field
* reception: use getDolGlobalInt when suitable
Using empty() implies that the value actually exists on the stdClass at
$conf->global, but it's not always the case. getDolGlobalInt will handle
this smoothly by checking first, which solves warnings like those:
Undefined property: stdClass::$STOCK_CALCULATE_ON_RECEPTION
* ReceptionTest: add new test
The test checks the usual workflow of the Reception class, with, on the
one hand, the common CRUD operations:
- create
- fetch
- update
- delete
And on the other hand, the status handling for Reception:
- valid: STATUS_DRAFT -> STATUS_VALID
- setClosed: STATUS_VALID -> STATUS_CLOSED
- reOpen: STATUS_CLOSED -> STATUS_VALID
- setDraft: STATUS_VALID -> STATUS_DRAFT
The stocks lines are not tested yet, and the error cases, like any other
transition not described above, are not tested either. The permissions
for some of the operations are hardcoded for the test and there is no
failure check when the permission is not set yet.
