QUAL: deleteObjectLinked() element value matching add_object_linked()

[altairis-noe]

FIX: deleteObjectLinked() element value matching add_object_linked()

CommonObject::add_object_linked() uses CommonObject::getElementType() to set element type in db. So should CommonObject::deleteObjectLinked(), or we might not delete previously created links

[eldy]

Can you describe how to reproduce the bug from screen ?
If you can't from screen, PR must be pushed into develop as it means it is a code quality enhancement.

[altairis-noe]

I wouldn’t say code quality enhancement, but it wouldn’t show in Dolibarr screen either.
I’ll try and describe the use case.
I have a module in custom named module, with an object in it. I use $object->add_object_link() in, let’s say, an order.
In table llx_element_element, I will have

sourcetype => module_object, targettype => commande

If I delete my object, or call deleteObjectLink() for some reason, as $element is object and not module_object, the entry in element_element will stay there, causing unwanted (and potentially misleading) information to rot in the database.
This PR corrects that.
So this is not QUAL, imo, this is FIX!

[altairis-noe]

Does it make sense for you, @eldy ?

[eldy]

Does it make sense for you, @eldy ?

As this affect only external module, this can't be categorized as a bug of dolibarr, but as an enhancement to allow a use case provided by external modules that is not yet possible. So you must push it into develop.

[altairis-noe]

I would’n’t say I agree, @eldy but I won’t argue 😉 Thankfully, the PR works on develop, so I just changed the target branch!

[altairis-noe]

Is it all good for you now, @eldy?

[altairis-noe]

Hey there @eldy are we OK to merge this ?