Purpose of this commit is to rename and reorder views by main model. It
allows to better understand module organization and find views one may have
to update.
Task-2678295
Part-of: odoo/odoo#79599
Steps to reproduce:
- On a company with multi currency
- Set the company currency rate to 1, and the foreign currency
to 0.273748
- Create a vendor bill
- Set first the foreign currency, then select a product with a
tax to 21% and a price unit of 155.32
- Go to 'Journal Items', the 'tax paid' line debit is computed to 119.15
- Reselect the foreign currency on form.
- Now the 'tax paid' line debit is computed to 119.16
The total is also impacted as the tax changed.
Explanation:
Before this commit, the taxes was both computed in foreign currency and company currency. However, when setting a new currency or changing the date, the taxes wasn't recomputed but the new conversion rate was applied.
This commit is fixing the issue by applying the same logic as in 14.0: the taxes are always computed only the foreign currency, then the conversion rate is applied to get the accounting balance.
opw-2569668
closesodoo/odoo#79618
X-original-commit: 11f5fcfb577b117b279f5d96095e9c0798d78bbd
Signed-off-by: Laurent Smet <las@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce :
- Install website module
- Activate (and translate website) French language
- Go to translated terms and fetch for "Discard" in website module
- Replace the translated value by "Ne pas sauvegarder"
- Go to Website -> Configuration -> Websites
- Select main website and change language to french then save
- Go to Website and edit homepage
- Add any block
Issues :
On top of editor sidebar, buttons are not displayed correctly.
Solutions :
Add css class `d-flex` to the div arround the buttons.
opw-2683602
closesodoo/odoo#79612
X-original-commit: 772156078418544907f9073e242e4491ddae1e5d
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Delete obsolete suggested_recipient_info with isCausal and ensure thread is
required on it.
This is intended to prevent crashing when creating a new partner from a
lead.
Task-2654859
closesodoo/odoo#79619
X-original-commit: fdbbed270d0c266a0e495136b461a4c40f8394bf
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, automated actions could not raise "normal"
errors anymore (e.g. UserError). Indeed, since the wowl refactoring,
it always shows the custom BaseAutomationErrorDialog when an error
is thrown in an automated action, even if it is a standard error
well-known by the framework. Before the wowl refactoring, those
errors were handled normally if possible, and when it wasn't the
case, the custom BaseAutomationErrorDialog was used.
This commit restores that behavior.
Complete steps to reproduce:
- Install base_automation module
- Install an app for the base_automation to trigger (e.g. Sales)
- Turn on debug mode
- Go to Automated Actions
- Create an action with Action To Do is Execute Python Code and the Trigger is On Creation & Update
- Set the model to your app (e.g. SalesOrder)
- Put `raise UserError('Test')` in Python Code section
- Go back to the app, try to create a new record in the model you set for the automated action to trigger
- Compare the result with 14.0
closesodoo/odoo#79611
X-original-commit: d65d742de1b30a00b3ffd872c042e002736f7f6b
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
The constrains on orderpoint location being related to the warehouse view
location was too restrictive especially in a complex subcontracting flow
with dropship.
This commit change the constrains to only be triggered if the two
location to be compared have both a warehouse.
closesodoo/odoo#79593
X-original-commit: 871cd6ad2d986ee1c28804aeeee63a001156154a
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Expected Behavior
The total amount and total taxes amount in invoice, purchase order and offer should be formated with the correct formating options (related to the client's location), and with the correct currency symbol, as it was the case in V14
Observed behaviour
In V15, these amount are written as pure numerical values (eg : 1452.24 instead of $1.452,24). This is the case in every generated pdf, as well as in the user portal preview(s), but not in classical form view(s).
Reproducibility
This bug can be reproduced following these steps:
- Create a new invoice
- Validate it
- Preview it in the user portal of download the printable .pdf
This can also be done with a purchase order, following the same steps.
Problem Rout Cause
The problem comes from the fact we read the wrong fields, using account.tax_totals.amount_total and account.tax_totals[subtotals].amount instead of account.tax_totals.formatted_amount_total and account.tax_totals[subtotals].formatted_amount.
opw-2666924
opw-2666553
opw-2665130
closesodoo/odoo#78762
X-original-commit: 2d632013af87f3d4e639bd79595fcbc69aeb4f51
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
- Configure a Receipt Printer for POS
- Create a Product with a long name (> 20 chars) and a big price
(i.e. PRODUCT BCDEFGHMWPGHHH - price: 9999.00)
- Create a Product with a short name (i.e. PRODUCT Z - price: 12.00)
- Make a POS sale with long product first and short as second
On the receipt, the line containing long product is too small to
contain also its price.
So the price will be on another line justified on the right.
But the following product will be stacked on the same line, making
the price on the receipt unreadable.
Someting like this:
-------------------
PRODUCT BCDEFGHMWPGHHH
PRODUCT Z 12.009999.00
The issue also appears for taxes lines and on the report of all sales
of current POS session.
This is due to a css style (float: right) applied to the price part.
opw-2639120
closesodoo/odoo#79595
X-original-commit: c565695b895a012a3953416fab60fe71d6f70665
Signed-off-by: Anh Thao PHAM <pta@odoo.com>
PURPOSE
Display "View document" link on notification emails using the 'light' layout
as done in standard layout.
Cleanup layout xml id propagation through composer or email sending in
mail and various applications.
SPECIFICATIONS: LAYOUT XML ID USAGE
Get rid of context usage and use a real field on mail.compose.message model.
Support old context key in composer for backward compatibility, working like
a default value for the field itself.
On template model: rename ``notif_layout`` parameter of ``send_mail`` to
``email_layout_xmlid`` to be coherent with naming used in other parts of the
code. Moreover it better indicates we expect an xml id.
On rating model: rename ``notif_layout`` parameter of ``rating_send_request``
to ``email_layout_xmlid``, for the same reasons as above.
In various wizards: support ``email_layout_xmlid`` context key when no field
is available, notably because this is still done manually in some wizards
like survey invite. Keep a fallback on ``notif_layout`` but remove support of
``custom_layout`` deprecated since quite a long time.
SPECIFICATIONS: ACCESS LINK
Light template is used is several notification processes as an alternate
layout to the classic one. It currently lacks any link to the document that
generated the notifications.
We add this behavior in this commit. Behavior is the same as the classic
notification email, aka a link to mail/view that chooses what to do based
on access rights and user status (internal, portal, ...).
SPECIFICATIONS: MISC
Remove ``mail_notification_borders`` as it is not used anymore.
LINKS
Task-2621326 (Mail: add 'view' button in 'light notification template')
Task-2647302 (Mail: add layout field in composer
closesodoo/odoo#76418
Related: odoo/enterprise#20903
Related: odoo/upgrade#2829
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Make CI/Style happy even if not really related to this PR.
Task-2621326 (Mail: add 'view' button in 'light notification template')
Part-of: odoo/odoo#76418
Light template is used is several notification processes as an alternate
layout to the classic one. It currently lacks any link to the document that
generated the notifications.
We add this behavior in this commit. Behavior is the same as the classic
notification email, aka a link to mail/view that chooses what to do based
on access rights and user status (internal, portal, ...).
Task-2621326 (Mail: add 'view' button in 'light notification template')
Part-of: odoo/odoo#76418
RATIONALE
Currently we can specify email used for notification layouting through context
use in mail composer. It is then propagated to message_post, stored on
mail.message and used to encapsulate emails sent based on posted messages.
SPECIFICATIONS
On template model: rename ``notif_layout`` parameter of ``send_mail`` to
``email_layout_xmlid`` to be coherent with naming used in other parts of the
code. Moreover it better indicates we expect an xml id.
On rating model: rename ``notif_layout`` parameter of ``rating_send_request``
to ``email_layout_xmlid``, for the same reasons as above.
In various wizards: support ``email_layout_xmlid`` context key when no field
is available, notably because this is still done manually in some wizards
like survey invite. Keep a fallback on ``notif_layout`` but remove support of
``custom_layout`` deprecated since quite a long time.
Task-2621326 (Mail: add 'view' button in 'light notification template')
Task-2647302 (Mail: add layout field in composer)
Part-of: odoo/odoo#76418
RATIONALE
Currently we can specify email used for notification layouting through context
use in mail composer. It is then propagated to message_post, stored on
mail.message and used to encapsulate emails sent based on posted messages.
SPECIFICATIONS
Get rid of context usage (``custom_layout``) and use a real field on composer
model: ``email_layout_xmlid``. Use now a default value coming from context
(default_email_layout_xmlid) instead of custom_layout.
Support old context key in composer for backward compatibility, working like
a default value for the field itself.
Task-2621326 (Mail: add 'view' button in 'light notification template')
Task-2647302 (Mail: add layout field in composer)
UPG odoo/upgrade#2829
Part-of: odoo/odoo#76418
RIP ``mail_notification_borders``. You were a joyful comrade.
Task-2621326 (Mail: add 'view' button in 'light notification template')
Related to odoo/upgrade#2829
Part-of: odoo/odoo#76418
Just separating notification layouts from templates used for various discuss
or chatter related notifications. Purpose is to have shorter but cleaner
files.
Task-2621326 (Mail: add 'view' button in 'light notification template')
Part-of: odoo/odoo#76418
Give the language in the context
closesodoo/odoo#79594
X-original-commit: 9939a0cbfae814f6b4d66c0ca45e0a84d3f57836
Related: odoo/enterprise#22205
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Once again, beaten by the unique term constraint and in conflict with
the same term in `web` module
X-original-commit: 21224e3a6d99d6b7e14529e67feabaac6df9d910
Part-of: odoo/odoo#79594
Only purchaseable products are not searchable in the lines of debit notes
and credit notes if this account moves are created from their tree view with
the CREATE button. This changes make that this behavieour were also if we
create this account moves from the buttons in the invoices "ADD CREDIT NOTE"
and "ADD DEBIT NOTE".
closesodoo/odoo#78266
Task: https://www.odoo.com/my/task/2543493
X-original-commit: 461801335b1bce1390f0e482648eb5eac7c7e3a8
Signed-off-by: Florian Gilbert <flg@odoo.com>
Commit d6abfbade9fb7f6dd6b3253551c559b1c7e6ece5 made it so we directly
reference a move's source origin via _get_source_document(). Normally
this is fine when the labels are created because labels would never be
created for a move without a source document, but this isn't safe when
the label is accessed via another way (e.g. test_reports). Therefore,
let's add in a check to prevent a error from trying to access
False.name.
closesodoo/odoo#79585
X-original-commit: 8abba9c3c0c48241e017e87045f392dc403a28e9
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
How to reproduce the problem:
- Install the Sales and Invoicing apps
- Create a simple SO with a product
- Create Invoice -> Down Payment (percentage) 30% -> confirm
- On the SO -> Create Invoice -> with Deduct down Payment -> confirm
- On that invoice -> Add Credit Note -> Reverse -> confirm
On the SO, the Down payment is not counted as invoiced, even tough it
was already paid and not refunded. If the user wants to create a new
invoice, the system will create one with the full price (not taking the
already invoiced Down Payment into account).
Cause of the problem : when computing the quantity to invoice for
the SO, a condition was avoiding preventing the down payment invoice
line to be taken into account in a way that it was just ignored.
I don't really understand the reason for this condition, as
it specifically ignores the down payments, while it should not be
ignored.
When creating the draft for the refund invoice, the down payment's SOL
is correctly updated as `line.untaxed_amount_to_invoice == 0` is true.
But when confirming the invoice, the values changed and the condition
is thus not met anymore.
opw-2491225
closesodoo/odoo#79572
X-original-commit: 99e8d4ad33bcdb27f7632a9ba5a5a2886d074ed5
Signed-off-by: Roose Pierre-Rodéric ( prro) <prro@odoo.com>
Purpose
=======
This commit adds a default product called "Access Course" to the
database when you have the `website_sale_slides` installed.
This commit also starts the transition for courses products
into `event ticket`-like products
Specifications
==============
This product is already created in order to help the users start to sell
their courses.
We also added a new type of product named `Courses`.
This will be used to create courses and easily work with courses products.
The commit adds the list of all the courses that the will gain access to
when he will buy the product inside of the cart and in the right column
whe it appears.
It also adds the same list when the product is inserted into a sales order.
The commit adds the choice of enroll policies in the front-end when
`website_sales_slides` is installed and of the corresponding product
if we are creating a paid course.
Task-2636092
closesodoo/odoo#77990
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Report client action can need context data to be properly be
displayed. But because all the required data is not put in the url,
reloading didn't work.
However, there is the current action data kept in the session storage
which is a solution to avoid the described problem. But it didn't
work because of the implementation of the report client action execution.
It was in reality executing two actions: one for the report, gathering
the data and fallbacking to a client action. By doing this, the
session storage would not have the necessary data kept for reloading the
page.
The fix is simply to duplicate the code of the client action execution
instead of calling doAction again.
closesodoo/odoo#79567
X-original-commit: 3fc095c57888e5f69729e1a5a6edea97c4c098b6
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce the bug:
- Install sale_management and sale_mrp
- Create a product with BOM, which is a KIT and add any product in BOM line
- Create a SO for the product > Confirm
- Validate the delivery
- Cancel the SO > Set to Quotation > Reconfirm
Problem:
A new delivery order is generated while the ordered quantity = delivered quantity
This is because `_get_qty_procurement` wrongly computed the product quantity based on the moves quantities in the kit case.
opw-2647856
closesodoo/odoo#79560
X-original-commit: 1f6f7dc82cede9a9038178d70fc7c53f685c5748
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Problem : Free Shipping is not translated in delivery
New Behaviour : Free shipping will now be translated
opw-2679727
closesodoo/odoo#79557
X-original-commit: 511bede06788ffb94308dc36d33abadc466a3168
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
This reverts commit 9cc4d6956b71291958114196107b1889109e92a1.
How to reproduce the issue:
- Starts from a database with some modules installed (account).
- Install a module with data only (l10n_generic_coa)
The models are not setup and the data fails to install.
A proper fix would be to mark the registry as dirty when new models are
added and only setup models when needed.
Since the faulty commit was part of a bunch of optimization and the
impact of this particular one is quite small, reverting it is a quick
and easy fix waiting for a better one (maybe, one day).
closesodoo/odoo#79552
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
As it was confusing to have some autogenerated sum on the parent model
we show the proper tax value of the report
+ add missing report line to related taxes
closesodoo/odoo#79534
X-original-commit: 163e4c069a15c75d75df980c558a03cc89fd254c
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
No longer converts the date_planned of a purchase_order_line to the
middle of the day. In case of multi-steps receipts, this caused a
discrepancy between the actual receipt and the later internal transfers.
Let's say a reordering rule is triggered :
- The date is set to midnight for the procurement, so the internal
transfer's date is set to midnight as well.
- The date is increased to noon for the PO line, which define the PO
planned_date, which define the linked receipt picking.
- So in the end :
- Receipt is planned to day X at noon.
- Transfer from Input -> Stock is planned to day X at midnight.
Task-2656397
closesodoo/odoo#79523
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Remove the Purchase Security Lead Time from the computing of the
purchase order's picking deadline to better reflect that the shipment is
actually meant to arrive earlier than date + security lead time.
Also makes sure that receipts and subsequent pickings (multi-step
reception) are planned the earliest possible, not taking the purchase
security lead time into account.
Task-2656397
Part-of: odoo/odoo#79523
Fix the inconsistency of product_{min,max}_qty in orderpoint. Both have
different tooltip saying that the reordering rule would trigger if :
- min: forecasted_qty <= product_min_qty
- max: forecasted_qty < product_min_qty
As the tooltip of the product_max_qty is in fact correct, we adapt the
tooltip of the product_min_qty to match the reality.
Task-2656397
Part-of: odoo/odoo#79523
In some flow like subscription, invoices are sent by mail automatically to the customer.
Sometimes, the invoice must be approved by the government before sending the mail like the Mexican EDI.
This commit aims to add a custom method to detect when an invoice is ready to be sent to the customer.
PR (community): https://github.com/odoo/odoo/pull/78714
PR (enterprise): https://github.com/odoo/enterprise/pull/21809closesodoo/odoo#79504
X-original-commit: 3a29371eb70309f46e3b8938434287fefc23b351
Related: odoo/enterprise#22171
Signed-off-by: William André (wan) <wan@odoo.com>
Purpose
=======
Hide non-relevant fields for a portal user. E.G. we want to hide the
notification type, the menu customization... Because those fields
make no sense for a portal user.
In this PR we make onchange works on reified field to allow fields
depending on groups to be modified as regular onchange in form
view.
Force the non-internal user to receive notifications by emails since
they can not open Discuss.
Task-2508521
closesodoo/odoo#77766
Related: odoo/upgrade#2890
Related: odoo/enterprise#21420
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Hide non-relevant fields for a portal user. E.G. we want to hide the
notification type, the menu customization... Because those fields
make no sense for a portal user.
Force the non-internal user to receive notifications by emails since
they can not open Discuss.
Task-2508521
Part-of: odoo/odoo#77766
Co-authored-by: nounoubensebia <neb@odoo.com>
Purpose
=======
In the `res.users` view, we can add / remove a group of a user with a
simple selection / boolean field.
This trick is done with an override of "fields_get" to return fields
that don't exist, and override the create / write to write on the
"groups_id" when we write on those "virtual fields". So with this trick
we can create new fields in the `res.users` view by just adding a new
group.
So when you write on the virtual fields, it will add / remove a group.
But this implementation will not trigger the on-change of "groups_id"
(because those field do not exist).
With this commit, the "onchange" of `groups_id` field will be triggered
when you write on those virtual fields (and so the computed method
which depends on `groups_id`, e.g. the `share` field).
Task-2508521
Part-of: odoo/odoo#77766
Before this commit, the link popover was only available in the website
builder. Now it is available anywhere the wysiwyg is used.
Task-2678412
closesodoo/odoo#79542
X-original-commit: 161c5fc8e742294e8d85c889b4bf8d3d8cd484f5
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
In a previous commit, the reception report label was refactored to be
better, making this report obsolete. For migration purposes, we remove
it in this separate commit.
Previous COM PR refactoring: odoo/odoo#76411closesodoo/odoo#76147
Task: 2632884
Related: odoo/upgrade#2815
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Previously this setting was an application setting which meant the
report could auto-open at undesired times (e.g. internal picking when
multi-step). Instead we make it more flexible for the user's desires by
moving it to the picking type setting.
Part of Task: 2632884
Upgrade PR: odoo/upgrade#2815
Part-of: odoo/odoo#76147
Before this commit:
Some navbar app sections items were
not properly indented in dropdowns.
After this commit:
The indentation is restored, leading to
a clearer usage of the navbar menus.
closesodoo/odoo#79545
X-original-commit: e8fad2c01b627b9cf0b696d68a59ec773015d6cf
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce the bug:
- install delivery and sale_management
- Create a product with route "Buy + MTO" and a product with route "Buy"
- Create a SO with both products
- Confirm the SO
Problem:
A traceback is triggered, because in this case, we have two `stock.move`, so two` stock.rule`
therefore, when accessing the `propagate_carrier` field an error will be thrown
opw-2681427
closesodoo/odoo#79539
X-original-commit: 431fc082470df36bc2968f4e51423b41c0c08945
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
This commit normalizes the different feature/browser detection modules'
implementations to avoid difference between "newer" implementation and
legacy ones.
Its main goal is to ease future maintainability by having only one
single source of truth for feature detection and, also ensure fixes
applied to one version are applied everywhere.
closesodoo/odoo#79499
X-original-commit: 3b90e15983edcb79e6bd6e45685926cd4dfaae6b
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Following commit odoo/odoo@ce4e6bd4b1 ,
the DateTimePicker design was revamped but not the DateRangePicker.
This commit adapts the DateRangePicker's styling to match the
DateTimePicker's design.
closesodoo/odoo#79497
X-original-commit: c5c944f4240dba8f8b100d73ef1a9c8870c705a7
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
By being lazy loaded, the DateRangePicker library's CSS files where
loaded after the Odoo specific customizations (bundled in the common
assets), resulting in some CSS rules being overridden by the one from
the library.
This commit fixes it by removing the lazy loading of the library's
(S)CSS to be able to handle their loading order. Also as our
customizations requires SCSS pre-processing, they can't be lazy-loaded.
Note: the library's JS assets are stil lazy loaded to minimize the
performance impact of this change.
X-original-commit: 4436411b6fd898d1fa32a9149b7dc12efe3ef9f8
Part-of: odoo/odoo#79497
Following commit odoo/odoo@8c55713dcc ,
the DateTimePicker (TempusDominus) library's SCSS file was pushed so low
in the (S)CSS assets loading order that it overrides the Odoo specific
customizations (done in `datepicker.scss` file).
This commit restores the correct loading order, also taking into account the
changes (i.e. variables) introduced in the afore mentionned commit and
fixing necessary CSS rules (cf. selected day's color) to keep the same
styling.
X-original-commit: 7fd486cd93154d680cb69e3f34aa04478bc62a63
Part-of: odoo/odoo#79497
Since
https://github.com/odoo/odoo/commit/ebf8d67485f7f71f6eb51762298cf50c5835ee08
design-themes repo is not excluded from the cloc count.
The module website_animate that was used as beacon to identify
the folder that contains the design-themes as been merged into website.
We need a new one, theme_common seems a reasonable candidate
closesodoo/odoo#79512
X-original-commit: f493b43462b7db14bb7f2b444c189f284acb1a1d
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
The holidays count on the employee form is not consistent with the count on the dahboard.
The count on the employee form counts the holidays left based on the approved holiday.
The count on the time off dashboard counts all the holidays that are not cancelled or refused.
The time off counts should be consistent across the different screens.
Task-2670658
closesodoo/odoo#78953
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Thibault Delavallée