The reified view on the res users will be dropped in the following commit.
The previous commit adds support to define each group as a computed field on the res users.
This commit defines:
- A boolean field for each 'isolated' res.group, i.e. a group in the hidden category.
- A selection field for each 'Application' res.group, i.e. a group in a application category.
Example:
- The group to manage pricelist in sales becomes a boolean field
- The groups project user/manager become a selection field
The field `auth_signup_uninvited` is defined in the 3 aforementioned
modules, yet they are independant modules in respects to one another.
This means that whichever module is installed first will create an XMLID
for the field, if this module is uninstalled before the other two: boom!
crash when changing general settings because the res.config.settings
field set by the other two modules no longer exists.
To solve this, we simply ignore the field during ir_model_field.unlink()
Fixes#23171
The handling of analytic lines to sell is a little
mess. We can reinvoice analytic lines from timesheet
or expenses, or manual lines.
This commit tries to clean the code, factorize it,
make proper hook (see _sale_postprocess method)
and move specific in its corresponding modules.
Code was properly split, in order to make modules responsible
for only their own features:
- sale module handle the link of SO line to an analytic
line, and increment the delivered qty accordingly.
sale also provide the mecanism of determine magically
the SO lines of an analytic line with an expensable product
to reinvoice it at cost.
- sale_timesheet identifies the so line concerned when
timesheeting on a project directly. Also provide the domain
of analytic line when setting the SO line on AAL.
Cleaning is necessary for futher dev.
This removes the procurement.order model. To fufill their needs SO, PO, MO and
stock moves now call the _run method of the relevant procurement.group.
This mecanism is now only used for stockable product, tasks now uses their own
independent mecanism.
The _run method will check all the applicable rules and create directly the
needed model to fufill the need.
The modules stock, purchase, mrp, extends the _run method to implement their
specific strategy relevant for the rule type they define.
If an exception happens the message will be logged as a mail messsage on the
source model, for example, if a sales order cannot be fufilled the salesperson
will now see directly the reason.
OLD commit messages:
[WIP] procurement: removing procurement.order in stock, sale, purchase, sale_stock. WIP
fixup! [WIP] procurement: removing procurement.order in stock, sale, purchase, sale_stock. WIP
[IMP] Basic tests
[FIX] test not necessary anymore
[FIX] remove unnecessary print statement
[FIX] unnecessary test + why passing warehouse worked before?
[IMP] purchase: one move by purchase order line
[FIX] purchase: correct inventory tests and pass move_dest_ids among procurements
[FIX] because of bad cherry-pick merge
[IMP] make mrp pass by adding move_dest_ids there too
[IMP] tests of sale_mrp, no need for cancelpropagation then
[IMP] better to consistently use recordsets also for one2many
[FIX] purchase_requisition
[FIX] Exceptions should trigger errors, which should be caught in the tests
[FIX] sale_mrp: remove usage of procurement.order and use sale order name instead of sol
[FIX] stock_dropshipping: add sale_line_id on purchase_line_id
[FIX] Remove pdb
[IMP] add stock_dropshipping files
[IMP] stock: search carrier through sale line instead of procurement group
[IMP] add procrule test and preision needed when updating sol
[FIX] sale_order_dates + [IMP] procurement exceptions by scheduler
[FIX] No need to return task
[IMP] move file as name changes and add corrections
[FIX] Continue Run Schedulers wizard fix
[FIX] name issues of takss
[FIX] updating sale order line, but there is still a problem with the recompute
Adrian Torres