QUAL Rename column fk_origin_line on shipment lines into fk_elementdet to match a generic use. #28989
Conversation
Adapting the query and code to the new table format
| @@ -24,7 +24,7 @@ create table llx_expeditiondet | |||
| rowid integer AUTO_INCREMENT PRIMARY KEY, | |||
| fk_expedition integer NOT NULL, -- ID of parent object | |||
| fk_element integer, -- ID of main source object | |||
| fk_origin_line integer, -- ID of line of source object (proposal, sale order). TODO should be renamed into fk_elementdet in SQL files and code in same PR | |||
| fk_elementdet integer, -- ID of line of source object (proposal, sale order) | |||
There was a problem hiding this comment.
If you update the field in table used to create a new instance, you must also add a line into file htdocs/install/mysql/migration/19.0.0-20.0.0.sql to migrate the field name.
Also, it seems the field is still used in a lot of other file with name fk_origin_line, all mention to this file for expeditiondet must modofied in same PR.
There was a problem hiding this comment.
Are there interractions with the sql database in other files?
Normally, the principle of the model is that you only use it for sql interractions, right? For other files, we use the object properties. That's why, for the moment, I've left the fk_origin_line property, but put the value of the new field in it.
There was a problem hiding this comment.
@eldy I must not be very clever, but I can't find anything about the old sql field in the files. Can you give me an example of a file where the old sql field is still present?
There was a problem hiding this comment.
Ηι @zephyriony
You have to also modify at least following files so not to break things
https://github.com/Dolibarr/dolibarr/blob/develop/htdocs/install/mysql/tables/llx_expeditiondet.key.sql
https://github.com/Dolibarr/dolibarr/blob/develop/htdocs/install/mysql/migration/19.0.0-20.0.0.sql
https://github.com/Dolibarr/dolibarr/blob/develop/htdocs/expedition/card.php
https://github.com/Dolibarr/dolibarr/blob/develop/htdocs/commande/class/api_orders.class.php
https://github.com/Dolibarr/dolibarr/blob/develop/htdocs/commande/class/commande.class.php
https://github.com/Dolibarr/dolibarr/blob/develop/htdocs/product/class/product.class.php
https://github.com/Dolibarr/dolibarr/blob/develop/htdocs/product/stock/replenish.php
https://github.com/Dolibarr/dolibarr/blob/develop/htdocs/core/modules/modExpedition.class.php
https://github.com/Dolibarr/dolibarr/blob/develop/htdocs/product/reassort.php
https://github.com/Dolibarr/dolibarr/blob/develop/htdocs/expedition/list.php
https://github.com/Dolibarr/dolibarr/blob/develop/htdocs/expedition/dispatch.php
https://github.com/Dolibarr/dolibarr/blob/develop/htdocs/core/lib/sendings.lib.php
There was a problem hiding this comment.
Hi @zephyriony
Can you fix conflicts so i can help and push changes to your branch to complete this?
There was a problem hiding this comment.
Hi @sonikf
Yes thank you it would be great I have less time to deal with it now but I think it is an important point for the future version of Dolibarr ^^
I solved the conflict normally :)
rename fk_origin_line to fk_elementdet
rename fk_origin_line to fk_elementdet
rename fk_origin_line to fk_elementdet
eldy
changed the title
|
@eldy |
I think database is ready for standalone shipment/reception. Because we made a lot of change into structure (above all on reception side), and because freeze of v20 would start soon, i think we should not work on screens on shipment/reception anymore, except to fix regression we introduced by renaming. And we should wait next version for that. We already have a very high number of structural changes in develop, so it would be better to make a pause for v20... But i don't rule, coming contributions rules... it's just a point of vue. |
|
Ok I understand. |
* Fix PR #28989, create shipment line * Fix Phan * Update changelog * Fix stan --------- Co-authored-by: Laurent Destailleur <[email protected]>
New [Adapting the query and code to the new table format]
Modifying the fetch method