- Define 2 companies A and B. Delivery methods are linked to products in
company A
- Deactivate 'Share product to all companies'
- Create a user B in Company B only
- As user B, create a SO and open the drop-down list for delivery
methods
An access error is raised.
Delivery methods should follow the same record rules than the products
they are linked to.
opw-1815490
Steps to reproduce the bug:
- Set your company currency to USD
- Set multicurrency on your user
- Create a delivery method with a fixed price to 50$
- Create a SO with a pricelist in EUR
- Set the delivery method and check the price
Bug: It displayed 50€ while this amount should be converted
opw:1817666
Steps to reproduce:
* Create a sales order (SO).
* Assign a carrier.
* Don't press on "Set price" button next to carrier.
* Validate SO.
* Validate picking.
* Delivery line is added to the SO with price 0.
This is because the delivery SO line is added with the value of
picking carrier_price field, but that field hasn't been set.
If you modify on view carrier field, there's an onchange that
fills correct price, so I use that onchange method for getting
same results.
Use case to reproduce:
- Install delivery/batch picking
- Process 2 pickings in a batch.
-> Traceback due to ensure_one.
It happens because the action_done method in delivery is
not multi and batch_picking launch action_done on multiple
picking.
This commit makes action_done in delivery multi.
This merge changes the templates used to send notification emails. They
are currently defined as mail.template using jinja. We choose to make
them QWeb views. There are several reasons to do so
* those are not real mail.template records. Indeed they cannot be used
outside of the notification process as some values are computed
and not available on the mail.message record used to render the
template;
* we do not really need other fields than body. Indeed fields like
subject, email_from or email_to are computed from the notification
process;
* we do not want people to update the mail.template without knowing
the consequences, especially for fields like recipients that may
broke the mail gateway;
* using the html editor easily break the mail.template as it is very
custom and very to break without really realizing it.
It also simplifies template management as it lessens number of mail
templates people have in their list view of mail.template. It avoids
mixing technical and functional templates.
We move to QWeb templates as those are not too hard to customize and
allow to perform body rendering which is what we really need when
notifying people of a new message.
This merge also factorize the "custom layout" used in several addons
to use a single secondary template defined directly in mail. Indeed they
are using the same template. Therefore having it defined only once helps
editing or fixing it.
Please see sub commits for more details about the merge.
All those templates are basically the same except some bug fixes that
were not propagated about company. Let us use just the one we just
defined in the mail module.
In this commit we change notification templates used to render
notification emails from jinja-based mail.template to pure QWeb
templates.
There are several reasons to do so
* those are not real mail.template records. Indeed they cannot be used
outside of the notification process as some values are computed
and not available on the mail.message record used to render the
template;
* we do not really need other fields than body. Indeed fields like
subject, email_from or email_to are computed from the notification
process;
* we do not want people to update the mail.template without knowing
the consequences, especially for fields like recipients that may
broke the mail gateway;
* using the html editor easily break the mail.template as it is very
custom and very to break without really realizing it.
It also simplifies template management as it lessens number of mail
template people have in their list view of mail.template. It avoids
mixing technical and functional templates.
We move to QWeb templates as those are not too hard to customize and
allow to perform body rendering which is what we really need when
notifying people of a new message.
This commit does not change the functional purpose and layout of the
templates. Behavior should be the same before and after this commit.
This commit adds the possibility to chose between pounds and kilograms
to express the weight field on the product. This is done so that
companies that worked internally in pounds do not have to convert their
weights back to kilograms for a consistent computation of the rates in
delivery.
We complete the general settings with the selection of the weight's uom.
Validating the setting will create an ir.config.parameter. A static
method defined on product template will return the chosen UOM.
We display "weight_uom_name" on the form view so that the UOM is not
clickable/editable because we fear user would want to edit the UOM
instead of changing it in the res config.
We move the view definition allowing to fill the product's weight from
stock to product to help the generation of the intrastat report without
installing inventory.
We would like to make the "no item found" screens more appealing.
Before this commit, it shows a small help tip in the top-left
corner of the screen, just below the "Create" button.
With this commit, these help tips have been replaced by onboarding
screens, which consist of a picture and some text below, both of which
are horizontally centered.
The texts have been slightly changed, so that they are shorter and clearer.
Considered modules:
(A)
account,
account_asset,
account_budget,
account_test,
account_voucher,
analytic
(B)
barcodes,
base,
base_automation,
board
(C)
calendar,
contacts,
crm
(D)
delivery
(E)
event
(F)
fleet
(G)
gamification,
google_drive
(H)
hr,
hr_attendance,
hr_contract,
hr_expense,
hr_gamification,
hr_holidays,
hr_payroll,
hr_recruitment,
hr_timesheet
(I)
im_livechat
(L)
l10n_fr_sale_closing,
link_tracker,
lunch
(M)
mail,
maintenance,
mass_mailing,
membership,
mrp
(N)
note
(P)
payment,
point_of_sale,
post_mercury,
pos_restaurant,
product,
project,
purchase,
purchase_requisition
(R)
rating,
repair,
resource
(S)
sale,
sale_timesheet,
sales_team,
stock,
stock_account,
stock_landed_costs,
stock_picking_batch,
survey
(U)
utm
(W)
web,
website,
website_blog,
website_customer,
website_event_track,
website_forum,
website_quote,
website_sale,
website_sale_digital,
website_slides
install delivery
Create a SO with a shipper
Validate it
validate the delivery
Before this commit it was:
- impossible to do the setup for the delivery cost on the SO to get updated with the delivery validation
- the delivery cost on the SO did not update
This was because the stock API changed a bit a some functions were not here anymore
OPW 786500
The package weight is computed by summing all move lines related to it,
which is wrong, because if you have a package that is in two pickings,
its weight will two times bigger than the real weight.
To fix this, we will compute the weight based on the quants in the
package, except if we are opening the package from a pickin, it's weight
will be the sum of move lines of the package that are in the current
picking. This allow user to see the weight of a package after a put in
pack when there are not yet any quants in the package
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
Some countries, such as Canada, are using letters in their zip code.
When we check if the zip code is within the accepted range, we should
make sure to normalize it by making it case insensitive.
opw-767866
* can't compare a function and a float in Python 3 (it works in
Python 2, though it makes no sense and was just hiding a bug)
* no iteritems method on dict in Python 3 (use compat helper)
* P3-invalid "except" syntax (sadly pylint apparently does not have a
standard lint for that, though it's easy to catch... if you can run
the code under P3)
Thanks to @xmo-odoo and its Python3 virtual machine for spotting this
one (and shame on Python2 that does not crash when comparing a method to
a float because voilà).
When an order is shipped, a notification email is sent to the customer.
If there is a tracking URL, it is included in the email.
(and also a bit of refactoring)
Christophe Simonis