Oversight of 20b34ae867
This commit fixes the display condition of the small alert block on top of the
mass.mailing form view.
The condition was not working because it would hide the alert if:
('failed', '=', 0)
OR
('state', '!=', 'in_queue')
AND
('sent', '=', 0)
AND
('scheduled', '=', 0)
Instead, we want to hide it if:
('failed', '=', 0)
AND
('state', '!=', 'in_queue')
AND
('sent', '=', 0)
AND
('scheduled', '=', 0)
This would for example prevent showing that the mailing is "scheduled" or that
it has successfully been sent with various mailing statistics.
Task-2457227
closesodoo/odoo#67752
X-original-commit: 98786b70d92d8a3bdfb961945f475b64899cc2e0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before it was only done on MyCompany, but interferes easily
with other demo data. Better for the Italian localization
to try the demo immediately in IT Company.
We also added an Italian demo partner, so it is clear
which one can work immediately.
closesodoo/odoo#67615
X-original-commit: 91ff96a79121c1b7018f8a1f7fa9850170852c41
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: Josse Colpaert <jco@openerp.com>
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>
The landed cost journal (lc_journal_id) is not required by default as a
result it is possible to create a landed cost with no account_journal_id
and thus no company_id this will make the query in
_compute_allowed_picking_ids fail.
Issue caused by: #63742closesodoo/odoo#67675
X-original-commit: 3b9824f57d2bbe30a8a3f63d0decb2101b6b0a90
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
- Settings > Technical > Email > Outgoing Mail Servers;
- Create a new serve with no security;
- Test connection.
Before this commit, a traceback error is raised. This occurs because
SMTPException don't have 'smtp_error'.
Now, the UserError is shown correctly.
opw-2464796
closesodoo/odoo#67712
X-original-commit: f0e478a154b1f15146c7d95e0ffe146bb22b8cae
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Add report name and document prefix on l10n_ar data for
the following documents:
- (60) CUENTAS DE VENTA Y LIQUIDO PRODUCTO A
- (61) CUENTAS DE VENTA Y LIQUIDO PRODUCTO B
closesodoo/odoo#67720
X-original-commit: f61877763c601ee80107d92a414dd9ca13132f0e
Signed-off-by: Josse Colpaert <jco@openerp.com>
We also remove the country_id for the foreign/external_id as otherwise,
it would not be selectable if the country_id of the partner is not Colombia.
closesodoo/odoo#67711
X-original-commit: 46bf5b27aaf374d6fa458170bc936251b8595c24
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Signed-off-by: Josse Colpaert <jco@openerp.com>
In order to integrate and use GS1 nomenclature into `stock_barcode`,
adds a new module with GS1 nomenclature and rules, and overrides parsing
methods.
task-1968113
closesodoo/odoo#65858
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Co-authored-by: ryv-odoo<ryv@odoo.com>
Before this commit, on mobile in the Accounting app, the link in a
kanban card was not well placed.
After this commit, in mobile we consider a link as a block so he is
moved below.
Steps to reproduce:
* Open Odoo on Mobile
* Go to Accounting => Bug ("Create Manually" is in a strange position)
Task ID : 2200168 (4.a)
closesodoo/odoo#67692
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
when the partner is Tesoreria de la República, and exclude the credit note.
closesodoo/odoo#67630
X-original-commit: 8ca3ea063050f2ab2d19cce8a68116489872a734
Signed-off-by: Josse Colpaert <jco@openerp.com>
Before this commit, when a calendar view was resized the full view was
rendered again to recalculate the resize.
After this commit, we now set manually the new size.
This avoid to lose the current position-y in the calendar.
Steps to reproduce:
* Open a window (not maximized)
* Go to calendar (day/week view)
* Scroll to the end of the calendar
* Resize the window => the calendar returns to the begging.
Note:
By the same way it also fixes a performance issue in TimeOff's render as
it makes an RPC to calculate the popover for the year view.
Task ID: 2200168 (5.a)
closesodoo/odoo#66387
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Steps to reproduce the bug:
- Let's consider an included tax T (10%) and a product P (11€) with invoicing policy based on delivery
- Create a sale order SO with one line L with 2 P and T
- Confirm SO
Bug:
The untaxed_amount_to_invoice was 20€ on L instead 0€
The untaxed_amount_to_invoice must be 20€ when the delivery is processed
opw:2457660
opw:2457660
closesodoo/odoo#67682
X-original-commit: d6ed6b9fa204fcfcabf1c1c330b5ae8ada34744c
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Those are not launched anymore by default. Indeed framework and code followup
is not ready for that level of details.
Task ID-2480727
closesodoo/odoo#67678
X-original-commit: f950399e6e4aaaf88b743abfeb37a2de4c99fa5c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
According to last runbot state. Should probably be removed someday as actually
there is not much gain with those tests.
X-original-commit: dc05f873571ca60b7fbbb701a86760f13a6d3172
Identification type was always been overwrite by the _onchange_country even when just opening the contact form, this was always setting the is_vat identification type as default without taking into account if the user has defined their own default.:
* If Identification type is set and it is compatible with the country then we leave it as it is (this is the case the identification type has been set by a default).
* If Identification type is set but is not compatible with the country then compute and set the Identification type that is is_vat True for the country
Where country is the one set in the partner record, if not set will use the country of the move's company, if not defined then will use the country of the environment company
closesodoo/odoo#67628
X-original-commit: 8e9b1c404a71c0a7dce37c7f5f6ecef1396e0a1a
Signed-off-by: Josse Colpaert <jco@openerp.com>
Steps to reproduce the bug:
- Create an Expense E
- Create a report R from E in the journal J (type=purchase)
- Generate the journal entry JE from R
- Go to Accounting Dashboard and click on J in the kanban view
Bug:
JE was not displayed in the entries filtered for J
PS: When creating a journal entry from an expense sheet, the move_type of the entry
is 'entry'.
opw:2474729
closesodoo/odoo#67674
X-original-commit: 31ca461ee3a6b9560fe6d78642e8fe5017b1085e
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The "TypeError: Mixing apples and oranges" error message is raised when
users are using recordsets from different models together. The error
message was confusing some users thus have been reworded to be more
explicit.
The initial proposal was to replace "apples" and "oranges" by "torchons"
and "serviettes" but it was rejected because the French are not capable
not to mixup the two. They suggested to instead replace "apples" and
"oranges" by "pain au chocolat" and "chocolatine", this was rejected
because none of us understood the difference between the two, they both
are couques.
closesodoo/odoo#62266
Task: 2366612
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Steps to follow to reproduce the bug:
-Go to the Contact app
-Choose any contact
-In the contact form> go to the "sales & purchase" tab and try to assign a user in the "salesperson" fields
Problem:
You can choose any user regardless of their type. While normally we can only choose internal users
Solution:
Add a domain to the "user_id" fields to only see users of the kind "internal type"
opw-2468819
closesodoo/odoo#67642
X-original-commit: 1361686fe502be137a4757c9092fab4223d484f8
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Aurélien Warnon