Cannot create payment methods on entities other than 1

[atm-florianm]

Bug

Not sure this is a bug, but despite the dictionary llx_c_paiement having an entity column, I haven't yet found a way for an admin user to create new payment modes on entities other than 1.

Despite the form having a <input type="hidden" name="entity" value="1">, even if you override this (which, I grant you, we can't expect regular users to do), the override is overridden by this:

elseif ($value == 'entity') {
	$_POST[$keycode] = getEntity($tablename);
}

It seems strange to use getEntity there because it may (depending on sharings) return more than one value, which would result in an SQL syntax error.

@hregis maybe you have more information on this one.

This problem has already been reported under #25983, but not as the issue itself (only in a comment to the issue).

Also we have PR #26001 in which the getEntity problem was mentioned.

Dolibarr Version

17.0 (but 18.0 seems to behave the same)

Environment PHP

any

Environment Database

any

Steps to reproduce the behavior and expected behavior

On a Dolibarr having several entities (but no sharings configured), go to entity 2, then go to the payment modes dictionary and add a new payment mode.

Expected: the new payment mode is created on entity 2

Actual: the new payment mode is created on entity 1

Attached files

No response

[hregis]

@atm-florianm This is not a bug, for the moment it is not possible to customize the llx_c_paiement and llx_c_payment_term dictionaries by entity because the tables of propal, order, invoice and others use the rowid and not the "code" field of these dictionaries. It would be necessary to plan a big migration to use the "code" field of these dictionaries. @eldy ?

[eldy]

@atm-florianm This is not a bug, for the moment it is not possible to customize the llx_c_paiement and llx_c_payment_term dictionaries by entity because the tables of propal, order, invoice and others use the rowid and not the "code" field of these dictionaries. It would be necessary to plan a big migration to use the "code" field of these dictionaries. @eldy ?

Don't see why having a link on id is a trouble. All other dictionaries also are linked with the id but they can be specific per entities. Code abc in entity 1 may have a different meaning in entity 2.

2 solution.
Sharing accordong th share rules of parent object.
So if the proposals are shared between 1 and 2 we should have dictionnay of payment term shared using the same shared id (so 1 and 2) of proposals. But if orders are between 1, 2 and 3, sharing of payment terms should be between 1,2, 3 and not 1,2. So the sharing must depends on context of object.
No choice to do differently. But this will generate a lot of side effect.

Or sharinh according to sharing rule on payment mode table only.
In such a case, if an object is on another entity, we shoul be able to see the payment mode entry even if not into shared entities of payment. Or we should have a message "payment mode unknown, defined into another entity we don't have permission on"

This trouble has no real good solution. Only bad with bad side effect. But i don't lnwo what is the less worse...

[hregis]

when we create a new entity, some dictionaries are duplicated on this entity, these are dictionaries whose code is stored in the objects and not the id. The problem when using the id is that if we activate the customization of a dictionary in multicompany and we do not have this duplication and we use the data of the dictionaries of entity 1, if we deactivate a data of a dictionary it will be deactivated for all entities.

[hregis]

I can add to have 3 possibility,

1 use only dictionary of master entity
2 use master entity and current entity
3 current entity use own dictionary

[atm-florianm]

Thanks for your replies.

In our use case, we use Dolibarr 17 and we have some custom multi-entity managed objects (let's call them "O").

We need to disable some payment methods on some entities.

Historically, we stored the payment method as a code (O.mode_reglement) and we implemented the "disabling by entity" feature with additional, non-standard code (hooks + custom functions instead of Dolibarr's). This approach works, but has maintenance costs (when adding features or upgrading Dolibarr).

As part of refactoring efforts, we thought we would standardize this by using O.fk_mode_reglement (an ID) instead of O.mode_reglement (a code). This way, users would just have to disable the (un)desired payment methods in the dictionary for their entity.

I understand from your replies that our approach may not be the best today because we don't yet have a clear path to handling payment methods by entity and there are many problems that I didn't anticipate.

@eldy would it be possible to combine your 2 solutions using precedence rules ensure that dropdowns only show the same code once? like "object's entity" > "master entity" > "other entities included in the sharing"? I don't think payment methods appear in filters for lists so this wouldn't be too big of a problem, would it?