The problem is that the cache still thinks in the test that
it is in EUR and then it does a currency conversion for calculating the
delivery cost and the test will fail in L105 of test_delivery_stock.py
By invalidating the cache after the sql that change the currency of the
company, we solve it.
(someone should refactor those tests though)
closesodoo/odoo#67790
X-original-commit: f0a1e7c35bd8cd17149d1d54bfe5b9eec12a0814
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: Josse Colpaert <jco@openerp.com>
Documento di Trasporto (DDT)
Whenever goods are transferred between A and B, the DDT serves
as a legitimation e.g. when the police would stop you.
When you want to print an outgoing picking in an Italian company,
it will print you the DDT instead. It is like the delivery
slip, but it also contains the value of the product,
the transportation reason, the carrier, ... which make it a DDT.
We also use a separate sequence for the DDT as the number should not
have any gaps and should only be applied at the moment the goods are sent.
When invoices are related to their sale order and the sale order with the
delivery, the system will automatically calculate the linked DDTs for every
invoice line to export in the FatturaPA XML.
Task 1914640
X-original-commit: bde2be069910596df9433df684309fe9f21a494a
We need this refactor for the ddt module to be able to pass
the necessary information easily for the link between the invoice
lines and the ddts.
X-original-commit: a4fb5c93f094dc1cd4de75664b7e232bc505e05c
Fine tuning of f816c326f348ff78a982f91a736cc005d3e0cd31
We should not look at the `seq` when grouping again.
opw-2472061
closesodoo/odoo#67788
X-original-commit: fd36a69a6ed1484d6b7570dae3ff63d3f12ad035
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Issue:
- Activate "Analytic Tags" and "Analytic Accounting" Settings
- Create an Analytic Tags and select "Analytic Distribution"
- Create Product -> Product type: Storable product, Update Quantity as
100, Sales Price like 100
- Product category -> Costing Method: Average Cost (AVCO)
Inventory Valuation: Automated
- Create Analytic Defaults Rules -> select created Analytic Tags
& Product.
- Create a SO -> Confirm it -> Delivery -> Validate it
then system give validation message message:
"The operation cannot be completed: another model requires the record
being deleted. If possible, archive it instead.
Model: Analytic Line (account.analytic.line),
Constraint: account_analytic_line_group_id_fkey”
But can be validated from the Inventory app.
Technical information:
It is due to the `default_group_id` in context put in
`action_view_delivery` method, it context key allows to create delivery
(tree view of `stock.picking`) with the correct `group_id`
("Procurement Group").
But the this name field is also used in the
`account.analytic.line` model. Moreover, the
the `_prepare_analytic_distribution_line` doesn't return any value for
`group_id` which means, that at the creation of the
`account.analytic.line` the `group_id` (id of `procurement.group`)
which will wrongly used.
Solution:
Because the `group_id` field on `account.analytic.line` is a related
store of `account_id.group_id`. We can set it directly in the
`_prepare_analytic_distribution_line` with the correct value.
opw-2442493
closesodoo/odoo#67780
X-original-commit: c9f55c5ecf174414f8e9ed6df56170ac2c6d6e3e
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, in the kanban view of sale order lines, the
product's image was not visible.
This commit adds the image to be more consistent with the kanban view in
accounting.
Note: we have also tweaked the view in accounting for better clarity.
Task ID : 2200168 (6.b)
closesodoo/odoo#67691
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Issue:
On DB with a lot of product (e.g. 50K) the MO form is very slow
open/modify. It is due to the `_compute_allowed_product_ids` which
will set the `allowed_product_ids` fields with all product ids possible
(32K), then the `convert_to_record` will take a bunch of time to filter
out no-active product.
Fix:
In your case, to avoid to send bunch of ids to the web framework and
bypass the costly `convert_to_record`, we decided to simply (static) the
domain of `product_id` (`mrp.production`). The flow will be slightly
different (doesn't filter depending of `bom_id`) but still good and
maybe better (we can now modify the product without removing the
BoM/product in the MO form).
Remove `allowed_product_ids`.
opw-2475151
closesodoo/odoo#67753
X-original-commit: a1a4f4548b395127cf7f816379a63f2d47688893
Related: odoo/upgrade#2272
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Before this fix, the checkboxes were under the label on mobile.
The easiest fix is to not specify the col number as the field is
displayed with a width of 50%.
We now have two columns with 50% each that let more space for
long labels.
Steps to reproduce:
- Go to Events
- Configuration / Event Templates
- Go to the form view
- See "Display a dedicated menu on Website" options
closesodoo/odoo#67761
Task-id: 1929043
Related: odoo/enterprise#17022
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
The left css property computation wasn't usefull for ltr mode and
even worse, it introduced a bug when a horizontal bar was present
(as often on mobile).
The entire width of the table was used to compute the offset even
though we only saw part of it (scroll bar). It's why this left css
property was too high.
We can simply remove this logic as "right: 0" on .o_optional_columns
already do the job for the ltr mode.
Note that we still need to compute the left property for the rtl mode
to put the dropdown menu above the table. Otherwise it will be on his left!
Steps to reproduce:
- Go to Subscription
- Open an existing record
- Try to open subscription lines column dropdown
=> You need to scroll on the right to see it.
Related PR: https://github.com/odoo/odoo/pull/62472
Related Task ID: 1929043
closesodoo/odoo#67755
X-original-commit: 87c6f6338d267acaab90705f9d5ca8ad27ae30fd
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
These are throttled/debounced so the handlers are sometimes called after the
component has been destroyed.
opw-2451752
closesodoo/odoo#67754
X-original-commit: 852781cf64ad6bb10c552e106e93e2bb6035e34b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
when sale order is created from website sale then onchange is not called so value is empty
So here we use computed readonly False, store True for l10n_in_gst_treatment and l10n_in_journal_id in sale.order
X-original-commit: e44b9f44c81f418e0afea4aa24ed5bb41a2d210b
*: website
When declaring a SnippetOption, it is now possible to specify if the
display of the handles overlay should be visible on the snippet element.
By default, it is set to false, and if the selected snippet element does
not have any option that require the handles to be displayed, we will
display them on the first parent element that needs the handles to be
displayed.
In the context of an image, the handles will be displayed on the parent
column, as the image does not have an option that require the handles.
Part of https://github.com/odoo/odoo/pull/66550
task-2431684
closesodoo/odoo#66550
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
From the editor, when clicking on an image there is a new refresh icon
next to the delete icon that will open the media dialog to allow for its
replacement.
Part of https://github.com/odoo/odoo/pull/66550
task-2431684
Let's assume the following situation. We have a form view with a
one2many field A displayed as a list. In the list, there is a
one2many field B. B can't be edited, its value is computed by
an onchange. By default, it contains a single record (i.e. the
first value returned by the onchange is [[5], [0, 0, {...}]]).
When another field (say C) changes, B's value is re-computed to
[[5]]. Moreover, there is an onchange on A.
In this form view, let's assume the following scenario. Create a
new record and add a line to A. In this new line, B already
contains a record. Change C. This triggers an onchange that
returns [[5]], and B is now empty. It triggers a second onchange,
on the main record (as field A changed).
Before this commit, in this second onchange, B's value wasn't sent
among the other values of the new line.
The spec says that for onchanges, we must send all data, not only
what has really changed. From that perspective, the above scenario
highlights an issue.
That issue had two root causes. First, commit [1] wrongly fixed
another issue, and as a consequence, when building what to send
for the onchange, we didn't generate the values for fields that
hadn't changed inside an x2many (for added subrecords at least).
This commit reverts the fix of [1], and fixes it differently by
only sending a command 1 (update) after a command 4 (link to)
when the record is dirty (i.e. when it has been modified). See
[1] for context and details.
Second, the code that generates the values to send to onchanges is
the same as the one that generates the values to save records
(write or create). However, when saving, we only send what has
really changed. The values are at some point processed to remove
empty command lists from the list of changes (as it means that
nothing changed). However, here we ignored the flag that stated
whether we want all field values or just what has changed. This
commit takes the flag into account before removing the field's
value.
[1] https://github.com/odoo/odoo/commit/3e3a244e1afc4d74920a6302a14fa2590e8b6648
Issue reported in task~2352524
Model: account.move
One2Many (A): account.move.lines
Nested computed One2Many (B): tax_detail_ids
Field triggering the onchange (C): tax_ids
closesodoo/odoo#67739
X-original-commit: a3732031d38d7c7e93565cdd3cd4fdf838ae54ec
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Current behavior before PR:
When having a small screen, the composer in a chat window has no actual
shortcut to send the message.
Desired behavior after PR is merged:
'CTRL-Enter' keyboard shortcut will work for small screen size.
LINKS:
PR https://github.com//pull/65241
Task-2446076
closesodoo/odoo#67724
X-original-commit: 2542f731c5b06c3b451ecde7992d3bb45adb2c60
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
With this commit, 2 changes are made to the way that the
fields.Selection.ondelete cleanup action works:
1) We manually delete ir.model.fields.selection **before** the deletion
of ir.model.fields purposefully to **avoid** SQL CASCADE deletes, as we
do not know which selections are deleted in cascade and thus we cannot
perform the corresponding ondelete cleanup action (which is implemented
within the ORM).
2) In some actions, namely 'set default' and 'set null', we write a
"safe" value to the records containing the Selection being deleted,
before this commit this would go through the ORM (records.write()) but
this is problematic if there's a write override for the record's model
that raises an error for the field being written to. With this commit,
we first try to go through the ORM but if there's a failure (because of
the raise in a write override) then we will bypass the ORM and set it
with SQL.
opw-2451126
closesodoo/odoo#67616
X-original-commit: f5c7e861ee3ca0cdeb6c2f06d227ada07f923ed0
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Previously, an ondelete policy would be assigned to any required
Selection fields, the default policy being 'set null'.
Base fields do **not** require an ondelete value, since if they are
deleted there is no "data fix" to apply because the field's column is
dropped, and in fact it's error-prone to do so because during
`_process_ondelete`, the system would attempt to set to null fields that
were required (i.e. NOT NULL).
This issue is hidden by the fact that ir.model.fields are usually
deleted **before** ir.model.fields.selection and thus the ondelete
action won't be applied on the field with the original definition
(because it has probably been deleted by SQL CASCADE)
X-original-commit: 2e238f1e0202d65a98177939dac166dd659bb39c
When creating a journal entry in company C01, if user's sales team
belongs to another company CXX, the default sales team of the journal
entry is still the user's sales team.
To reproduce the error:
(Use demo data. Let C01 be the current company)
1. Add the `team_id` field to `account_move` form view:
- With web_studio
- Directly in the code:
```diff
diff --git a/addons/sale/views/sale_views.xml
b/addons/sale/views/sale_views.xml
index 92cb2a72c4d..acc0e91e890 100644
--- a/addons/sale/views/sale_views.xml
+++ b/addons/sale/views/sale_views.xml
@@ -1154,6 +1154,17 @@
</field>
</record>
+ <record id="account_invoice_view_form" model="ir.ui.view">
+ <field name="name">account.move.form.inherit.sale</field>
+ <field name="model">account.move</field>
+ <field name="inherit_id" ref="account.view_move_form"/>
+ <field name="arch" type="xml">
+ <field name="ref" position="after">
+ <field name="team_id" />
+ </field>
+ </field>
+ </record>
+
<!-- Update account invoice !-->
<record model="ir.ui.view" id="account_invoice_form">
<field name="name">Account Invoice</field>
```
2. Create a second Company C02
3. Edit the Sales Team 'Europe':
- Company: C02
4. Go to Accounting > Accounting > Journal Entries
5. Click on "Create"
Error: the default Sales Team is 'Europe'. However, this team belongs to
C02 and the user is creating a new JE in C01.
When creating a new journal entry, an `onchange` method uses the user's
sales team to define the JE's sales team.
However, the current user belongs to 'Europe', and the company of
'Europe' is now C02. Therefore, 'Europe' should not be used.
OPW-2375444
closesodoo/odoo#67733
X-original-commit: 67cd2ca3d80e5fc53f6c0f3ec73a0f90765dda73
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Commit f6b019fcfdd35a693e8af43ae38d10e31e96284a aims to fix the rounding
errors on AVCO valuated product when those exit stock. The issue was we
fixed the value and the unit_cost as it is rounded in the curruncy
precision. This is first wrong then useless.
The wrong part : in case the stock is empty and we make an outgoing
move, self.value = 0 so the unit_cost will be overridden to 0 while it
should stay at the standard price.
The useless part is that the unit_cost will be rerounded right after the
update to be written in database.
opw : 2380529
closesodoo/odoo#67718
X-original-commit: c2074b8c9ebf907f32a72ca6a5fadb4cd242a164
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Issue
- Create a database with 2 users
- Open the calendar application and create a meeting for you and the other user
- In the option:
set Privacy to 'Everyone'
set Show times as 'Free'
- Send the invitation to the other user
Access Error (rule: Hide Private Meetings)
Cause
The 'calendar_event_global' ir.rule is deprecated and related ir.rules
are now in calendar module (crm.meeting -> calendar.event).
Solution
Remove rule since deprecated.
opw-2469433
closesodoo/odoo#67706
X-original-commit: c2a3fdbc42e042440695c8a3fc3e657d910d2d5c
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
In this commit -
1) Added new field propagate_carrier_id in stock.rule and propgate
carrier in PICK PACK and SHIP if it is ticked.
2) Allow to print Label at any stage of PICK PACK and SHIP after
validation of picking from chatter.
Task-2363484
closesodoo/odoo#62851
Related: odoo/enterprise#15148
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Before the commit, if an exception occurs there was an error saying:
`TypeError: _handle_exception() takes 2 positional arguments but 3 were given`
Impacted versions:
- 12.0
- 13.0
- 14.0
X-original-commit: 47d6fa4ff6e78a33691c22b08504ce03e6796c9a
This provides a standard CoA with basic taxes and
fiscal positions.
closesodoo/odoo#68156
X-original-commit: eb41f0de553906e09d199190544c878a9d1a7e85
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
To reproduce:
1. set WH receipt in 3 steps
2. create a "receipt in 2 steps" route for product
3. create a PO with product "receipt in 2 steps"
In inventory, we will see this product still follow the "receipt in 3
steps" route.
This is caused when we create move for PO, we prepare the route_ids
according to warehouse's route_ids. After the move has it's own
route_ids, it will not search for route set on product or product
category (which should has higher priority over warehouse route).
To fix it, we remove the route_ids when create the move for PO. A route
will be found when the move being comfirmed.
Task 2448439
PR #65509
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
We also inject a context key to ignore prediction in case account_predictive_bills (enterprise) is installed. This way, having the same label on invoice lines generated by the helper will still behave in the same way, even if enterprise is installed.
closesodoo/odoo#67998
X-original-commit: b6c37754532ae6a7cc1f68a345fde6258abdc893
Related: odoo/enterprise#17125
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Add an additional report called "Voucher/记帐凭证" to print option in
account.move form view.
A library "cn2an" are required to conver a number to "amount in
words/大写金额" for Chinese financial usage.
Task 2179744
closesodoo/odoo#68121
X-original-commit: 0f6fdce76809af7e965f672970d74594a337f6fb
Signed-off-by: Josse Colpaert <jco@openerp.com>
Before this commit when we update the email_from field on lead with only
formatting differing from partner a warning ribbon was displayed. It
considered email had changed and had to be propagated. Moreover unnecessary
update on partner was done to propagate the new email onto the customer.
In this commit we propagate email only if normalized versions are different.
It means that if lead email_from is "Hermes Conrad <email@example.com>" and
partner email is "Jonathan Conrad <email@example.com"> no update from lead
to partner is performed. Indeed normalized versions are the same.
Task ID-2461308
PR odoo/odoo#66890
X-Original-Commit odoo/odoo@3dd972c35bclosesodoo/odoo#67859
Related: odoo/enterprise#17191
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to improve phone, email and mobile synchronization
tests for lead / partner. Notably
* mobile is not synchronized: only a void mobile is set to partner's mobile
when changing partner. It is not synchronized back onto partner;
* email / phone are correctly synchronized;
* phone_sanitized is computed on both lead and partner based first on mobile
then on phone. It means records having the same phone numbers could have
different phone_sanitized values if mobile numbers differ;
Task ID-2461308
PR odoo/odoo#66890
X-Original-Commit odoo/odoo@0adecd9a6e
Steps:
- Install Projects
- Go to Settings / Translations / Languages
- Install Dutch
- Go to Settings / Users & Companies / Users
- Edit demo:
- Language: Dutch
- Go to Projects
- Click the three dots on the first project in the dashboard
- Click Share
- Select demo as recipient
- Send
- Go to Settings / Technical / Email / Emails
- Click the email you just sent
Bug:
The email is not translated in the partner's language
Explanation:
The context of the template didn't take the current partner's language
into account since it was out of the partners loop.
The subject of the email wasn't aware of the partner's language as the
context hadn't been changed.
Wrapping the translations with the right `lang` context value fixes the
issue.
Also, the subject used the formatted string as the translation source.
This makes it impossible to find a matching translation since the source
is different every time.
opw:2475398
closesodoo/odoo#68162
X-original-commit: e446233a1b454ab1aa883609fd0b8a588fec9f00
Signed-off-by: backspac <backspac@users.noreply.github.com>
Steps to reproduce the bug:
1/ Install these apps: Sales, Planning, Employees, Project, Timesheets
2/ Add some employees (stay below 20 employees)
3/ Create a project with Planning, Timesheets and Billable
4/ Click on the overview
Bug:
List of all employees
opw:2460616
closesodoo/odoo#67850
X-original-commit: 3cf66c4ed482bb14973b57cacbe4ca56b93650d2
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Previous default website logo of the 'website' module ('YourLogo'
image) looked like a text and not like a proper logo, so it has been
replaced by a more stylised, gray-coloured, version, as a svg.
--
task-2448746
closesodoo/odoo#68075
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Odoo has made some modifications to the method
_compute_invoice_taxes_by_group from de Account module,
so we need to update the inherited method in the argentinian localization
Improves:
- Don't depend on price_subtotal to compute amount_by_group
- Show taxes when they are zero on invoices print
closesodoo/odoo#68178
X-original-commit: 011631a38564bcbdd8625428b9f897aefefce270
Signed-off-by: Josse Colpaert <jco@openerp.com>
The problem that occurs before of this commit, is due the base of the taxes is in the currency of the company not in the invoice currency. For that the value that shows in this cases for the base is not correponding for the symbol of the currency.
After this changes we show the correct value an symbol for the base converting the value when is necessary.
X-original-commit: 4fd4f82ecd1b97f608168baaa780844f68e8a9d7
Purpose of this merge is to provide some fixes and additional tests for
event mail schedulers.
Notably
* do not autocommit when running event mail schedulers in test mode
* allow event user to confirm registrations even with mail schedulers
* respect scheduled date when calling mail schedulers execute
Improve tests.
Related to Task ID-2414658
COM PR #68158closesodoo/odoo#68167
Forward-port-of: odoo/odoo#68158
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
We do not want to fail ever if loading the attachment fails.
We still log a warning in every case though.
Some malformed PDFs lead to seeking the wrong bytes while looking for
some parts, raising a ValueError
closesodoo/odoo#68171
X-original-commit: f4cc0579a3e0ee9c117c7dd0f6090edc6e94384d
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
In this commit we ensure calling ``execute`` method on communication schedulers
do not send emails or SMS if their scheduled date is still not achieved.
Currently only the cron method does it (see ``run``).
It is now safe to call ``execute`` directly on event communication schedulers.
Related to Task ID-2414658
COM PR odoo/odoo#68158
X-original-commit: 353bc5de9fafbc1527c382614e02438ee799c8a4
Due to ACLs it is currently impossible for event users to confirm a draft
registration if schedulers are involved. Indeed it implies updating the
scheduler which is not do-able for them.
In this commit we sudo the update of schedulers, as this is a technical
object and access is granted through registrations.
Related to Task ID-2414658
COM PR odoo/odoo#68158
X-original-commit: 73d09268922a7d242af85e36a3d81ed25ab4ca33
In this commit we improve event communication scheduling tests. We make tests
more detailed and use mail tools to ensure content. We also check scheduled
dates and use freezegun to ease date management.
Related to Task ID-2414658
COM PR odoo/odoo#68158
X-original-commit: 1a66d9cb57dc17b697b7a56effa91de3a4b50bd7
Otherwise it creates a lot of issues in your tests and database. Always avoid
that kind of error-prone statements in testing mode.
Related to Task ID-2414658
COM PR odoo/odoo#68158
X-original-commit: 3ad9126375e74071fec47f402f1fc63f98b755b6
Josse Colpaert