Before this commit, orders were not confirmed when there was more than
one transaction linked to them, regardless of their state.
As of now, we check if there is only one confirmed transaction (meaning
that the state of the transaction is either 'authorized' or 'done').
Fix 4d2b04a843
task-2906040
closesodoo/odoo#95443
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The expense dashboard was displayed on the Expenses Analysis whilst it
shouldn't have.
closesodoo/odoo#95987
Signed-off-by: Kevin Baptiste <kba@odoo.com>
For zero percent taxes, when the repartition lines are defined as 0% of
the 0% tax, the DatiReipilogo elements are not generated.
This is because of the recent addition of a filter to the calling of the
_prepare_edi_tax_details inside of the function that generates the
values for the template. The filter specifies that the tax data
retrieved relates to repartition lines with a percentage > 0. This
excludes taxes that are 0% of a 0% tax (which would be the same as a
repartition line of 100% of a 0% tax).
The solution is to change the > to >= so that these 0% tax repartition
lines are included.
A test is created with an invoice with two 0% taxes. One tax has a 100%
tax repartition line, and one has a 0% tax repartition line. With the
fix, there should be DatiReipilogo for both taxes in the xml.
The reverse_charge_invoice tests are also fixed in order to ignore the
invoice name (which will change depending on how many invoices are
posted in the previous tests).
closesodoo/odoo#95966
Ticket-id: 2909394
X-original-commit: 089f59ef79c554d7517d8621bfaee03875ad6062
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”
- Tracking: by serial number
- BOM:
- Component: C1
- Create a storable product “P2”
- BOM:
- Component: P1
- Create a MO to produce one unit of P1:
- serial number: SN1
- Confirm and mark as done
- Unbuild the manufactured product
- Manufacture the same product using the same serial number again
- Create a new MO to produce one unit of “P2”:
- Component P1 → select SN1
- Try to confirm and validate the MO
Problem:
Get User Error: The serial number “SN1” used for component “P1”
has already been consumed
We do a search in the `stock.move.line` to find if the SN has already
been used in a previous MO, but there is no specific condition to get
only those used in an MO so the unbuild order is in the same condition
and therefore the SN is considered as it has already been used
opw-2883450
closesodoo/odoo#95935
X-original-commit: 5ac7f4d6fa5551ba7c6da49a52edf0a7df2d0745
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
*: bus, calendar, iap_mail, im_livechat, project, web.
In order to ease the PR introducing the websockets in Odoo, the bus service
has to be updated to be a wowl service. This PR takes care of it.
task-2053917
closesodoo/odoo#95824
Related: odoo/enterprise#29361
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Stpes to reproduce the bug:
- Create a storable product “P1”:
- tracking: Serial number
- BOM: 1 unit of C1
- Create the MO 1:
- produce 1 unit of P1:
- Create the SN1
- Create the MO 2:
- produce 1 unit of P1:
- Create the SN2
- Create an Unbuild order:
- Select the MO1
Problem:
You have the possibility to select any Serial number linked
to the product “P1”, whereas only SNs created in this MO can be selected
opw-2834529
closesodoo/odoo#95956
X-original-commit: 167b1668450c5af44bc1d36d1c7d59921bc2b811
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Adding a @depend decorator on product_id in the stock_move_line model can trigger a search on stock.move.line.product_id
When the number of StockMoveLine reach a million, a simple `SELECT id FROM stock_move_line WHERE product_id = XXX` can take 200ms.
When a transfer contains a few hundred StockMoveLine (ex: when dealing with serial numbers), the process of validating it will take a few minutes.
Indexing product_id will change the process time back to a few seconds.
OPW-2893131
closesodoo/odoo#95511closesodoo/odoo#95915
X-original-commit: b8156cf9a2d01448244c306c24c3c55687fd0d23
Signed-off-by: DavidFesquet <dafr@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Rémy Voet <ryv@odoo.com>
Since Bootstrap 5 migration, when we use the OWL `dropdown` component
it must have the class `o-dropdown-menu` and not `dropdown-menu`.
This commit replaces this class and also clean some CSS.
closesodoo/odoo#95899
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit allows multiple salespersons to collaborate on a lead without
erasing each other's data.
closesodoo/odoo#95042
Taskid: 2900372
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Since 4f984568e1, the css theme is not
correctly applied to the website theme selector.
The order in which the css rules were applied without the
'.o_legacy_kanban_view' selector removed a margin from the
kanban_record element.
closesodoo/odoo#95936
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Before the change added in odoo/odoo#87990 the badges on the result
view were aligned on the right. However, this broke the mobile design.
This was changed to a bootstrap column view but the alignment was lost
in the process.
It is brought back using a text-right alignment, making sure the center
remains clean and the view open and clear enough. However, for very
small screens they are displayed aligned on the left. The column display
is kept.
Also harmonizes the spacing of the badge of matrix_subtype.
Task-2908045
closesodoo/odoo#95545
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
In a multistep configuration, decreasing the quantity on a line of a
confirmed sale order may create some inconsistencies.
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Edit the existing warehouse:
- Outgoing Shipments: 3 steps
3. Create a storable product P
4. Set the on-hand qty to 5
5. Create and confirm a sale order SO with 5 x P
6. Process the PICK/PACK pickings
7. Edit the SO:
- Decrease the qty: 3 x P
8. In the SO's deliveries, open the return of the pack step (Output ->
Packing)
- Error: Nothing changes, there isn't any reserved quantity.
However, there are currently 5 x P at the Output location, so the
reservation should work
9. Inventory > Report > Stock Moves, list all SM related to P
- Error: The origin/destination moves of the pack's return (Output
-> Packing) are incorrect too: the origins contain the pick's return
(Packing -> Stock) while it should not contain anything and the
destination moves contain the ship move (Output -> Customer) while it
should contain the pick's return (Packing -> Stock)
`SM_ship`: SM used to deliver from Output to Customers
`SM_ret_ship`: SM used to return P from Customers to Output
`SM_ret_pack`: SM used to return P from Output to Packing
`SM_ret_pick`: SM used to return P from Packing to Stock
When confirming a move, we transform the move if its demand is negative:
https://github.com/odoo/odoo/blob/53b424d9e43b07fe7aa84ff00035fb7772ef6291/addons/stock/models/stock_move.py#L1239-L1247
We reverse the source/destination locations but we don't do the same
with the origin/destination moves. That is an issue: before reversing,
we have:
| SM | Qty | From | To | Origin | Destination |
|-------------|-----|---------|-----------|-------------|-------------|
| SM_ret_pick | -2 | Stock | Packing | / | SM_ret_pack |
| SM_ret_pack | -2 | Packing | Output | SM_ret_pick | SM_ret_ship |
| SM_ret_ship | -2 | Output | Customers | SM_ret_pack | / |
Therefore, reversing the source/destination locations without updating
the origin/destination moves does not make sense: we should reverse them
too depending on their direction (positive/negative) and their
source/destination location.
Also, before trying to transform the moves, we try to merge them:
https://github.com/odoo/odoo/blob/53b424d9e43b07fe7aa84ff00035fb7772ef6291/addons/stock/models/stock_move.py#L1236-L1237
This is relevant for `SM_ret_ship`: we find an existing SM (`SM_ship`,
qty=5) that can absorb the negative demand of `SM_ret_ship` (qty=-2). In
such case, we add the origin/destination moves of the negative SM to the
positive one. However, in the above case, it will create an
inconsistency: after the fix, at that point, `SM_ret_pick` and
`SM_ret_pack` have been correctly reversed, so we have:
| SM | Qty | From | To | Origin | Destination |
|-------------|-----|---------|-----------|-------------|-------------|
| SM_ret_pick | 2 | Packing | Stock | SM_ret_pack | / |
| SM_ret_pack | 2 | Output | Packing | SM_ret_pack | SM_ret_pick |
| SM_ret_ship | -2 | Output | Customers | / | SM_ret_pack |
| SM_ship | 5 | Output | Customers | (SM_pack) | / |
Therefore, adding `SM_ret_pack` to the destination moves of `SM_ship` is
incorrect. (Note that, without the fix, `SM_ret_pack` would be added to
the origins of `SM_ship`, which would be incorrect too)
Finally, the reservation (step 8) does't work because of two reasons:
- If there are some `move_orig_ids`, we use the done value of these SM
to assign the current SM. However, as explained above, there is an issue
with this field
- If there isn't any `move_orig_ids`, there is an issue with the procure
method. Its value is `make_to_order`: we skip the reservation for such a
value:
https://github.com/odoo/odoo/blob/53b424d9e43b07fe7aa84ff00035fb7772ef6291/addons/stock/models/stock_move.py#L1499-L1501
OPW-2889679
closesodoo/odoo#95263closesodoo/odoo#95926
X-original-commit: fb94c140a91aca26a56c5162d61b00b4a4b0d85b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
After the change in account_type field in account.account the old selection widget didn't work.
Fixing the selection widget and adding it back on acocunt_type field.
As account types cannot be custom anymore, the account types within the hierarchy can be hardcoded.
closesodoo/odoo#95821
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
When an invoice line has a display_type, account addon is expecting
account_id=False in vals. Replacing the normal dict access with a
`get` will fix the error when invoicing with note/section lines
without explicitly specifying the `account_id` to be false.
closesodoo/odoo#95894
Signed-off-by: Masereel Pierre <pim@odoo.com>
Before this commit, it happened that the domain selector
couldn't find the operator linked to the field.
This commit adds a fallback on the existing operators
to find an operator that matches.
for example the domain `[["name", "like", "M"]]` gave
`Name ? "M"`, now it correctly gives `Name like "M"`.
closesodoo/odoo#95891
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since 4f984568e1, the specific css style
was not applied correctly to the journal dashboard.
closesodoo/odoo#95886
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In legacy, the domain field had an `in_dialog` option that was
used to display a button that opens a dialog to edit the value.
This commit reimplements the `DomainSelectorDialog` in owl
and adds the option the new domain field.
closesodoo/odoo#95768
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Task 2850882 modified the behaviour of expenses to support working
with all purchase taxes, regardless of their 'price included'
configuration.
We missed a domain on the split lines though, so it was impossible
to use 'all taxes' when splitting an expense.
This commit resolves that limitation/oversight.
closesodoo/odoo#95627
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Reproduction:
1. Create an invoice, then save and confirm it
2. Print the invoice
3. The CSS spacing does not work in the PDF report
Reason: V13 uses Bootstrap 3 but Odoo V14 uses Bootstrap 4. In
Bootstrap 4, the margin class is defined in a different way.
Fix: Instead of re-defining mt32 mb32 in the css file, we use mt-4 and
mb-4 to create a similar effect for the margins.
opw-2654880
closesodoo/odoo#95925
X-original-commit: 510c3f38ad54a09167774bb1e46215b761978024
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Liu Jinjiu (jili) <jili@odoo.com>
Before this commit, patching a getter of a class made it enumerable
(`Object.keys({ a: 1 })` -> `["a"]`).
In javascript, getters of a class are not enumerable but
getters of an object are enumerable.
When patching, the system replaced the descriptor of the old class
member by the member of the object.
Now, it replaces some info of the old descriptor by the new descriptor
but not the entire descriptor.
closesodoo/odoo#95921
X-original-commit: fd7c2c0c14bfaac228abacb265278157eec4aad0
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
When `sale` is installed alone,
the test fails because it changes the field `product_uom`
which is invisible in the view because the user executing the test
doesn't have the appropriate group.
```
FAIL: TestSaleOrder.test_fiscalposition_application
Traceback (most recent call last):
File "/data/build/odoo/addons/sale/tests/test_sale_pricelist.py", line 292, in test_fiscalposition_application
line.product_uom = uom
File "/data/build/odoo/odoo/tests/common.py", line 2179, in __setattr__
assert not self._get_modifier(field, 'invisible'), \
AssertionError: can't write on invisible field product_uom
```
closesodoo/odoo#95910
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This is about the same than
d6ad39abba
but with account_accountant installed
```
FAIL: TestFormCreate.test_create_res_partner
Traceback (most recent call last):
File "/data/build/odoo/odoo/addons/base/tests/test_form_create.py", line 35, in test_create_res_partner
partner_form.property_account_payable_id = property_account_payable_id
File "/data/build/odoo/odoo/tests/common.py", line 2179, in __setattr__
assert not self._get_modifier(field, 'invisible'), \
AssertionError: can't write on invisible field property_account_payable_id
```
closesodoo/odoo#95903
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Actually it is not possible to add manually a printer.
With this commit we loop into all printer recorded in cups to
check if a printer is not automatically added.
If a printer does not match with a identifier automaticcaly generated,
it is added to the list of usable printer.
closesodoo/odoo#95709
X-original-commit: de03cbefd537503cd46cbecf1622bd2a547b4615
Signed-off-by: Masereel Pierre <pim@odoo.com>
When the user opens a document from the chat channel, the system opened the document, but the chat window is still there and covers the document.
closesodoo/odoo#95880
X-original-commit: 29fa81cc02e5f70ab4875164e290f8a69ffde2e3
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Add some classes to improve the alignment.
Quite difficult to deal with as we have a lot of inputs on the same line.
Follow of odoo/odoo#95725closesodoo/odoo#95815
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
When in point_of_sale, the screen when getting out of the TicketScreen
is the current order's screen. However, when all the orders are deleted,
no new order is created, thus, pos crashes when clicking back button without
manually creating a new order. With this fix, when the TicketScreen is
closed (either by clicking an order, or clicking the TicketButton or
clicking Back button), a new order is automatically created when there
are no more orders. The sequence of the orders is also properly tracked
which is important in the fiscal data modules.
closesodoo/odoo#95876
Task-id: 2886099
X-original-commit: 20a04a70ba8b24349054522632a53a9701313329
Related: odoo/enterprise#29394
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
This follows revision
odoo/odoo@9925c8fbaf
On creation of an orderpoint,
if warehouse and location are not specified,
set default warehouse and location
if warehouse is specified but not location,
set default location according to the warehouse chosen
(and not the location of the default warehouse, as formerly)
if location is specified, but not location,
set default warehouse according to the location chosen
(and not the default warehouse, as formerly)
if warehouse and location are specified,
let them, do not overwrite them.
closesodoo/odoo#95851
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
When the price of the products is displayed in the product screen, we
are now taking into account the taxes when the pos diplays taxes
included.
The issue is that we are using the taxes on the product, and we are not
applying the fiscal position of the current order on the price.
We are now taking it into account
OPW-2860737
closesodoo/odoo#95848
X-original-commit: e162a7084f584fc9b5d5b2db7f519b5b47ad6406
Signed-off-by: Masereel Pierre <pim@odoo.com>
The user executing the test is changing the UOM
while the field was invisible because the user
did not have the multi uom group.
Therefore, add the group to the user for the test
so the field is visible in the form.
This is related to revision
odoo/odoo@5ccc32fcf7
```
2022-07-12 11:59:39,526 22 ERROR master odoo.addons.purchase.tests.test_purchase: FAIL: TestPurchase.test_with_different_uom
Traceback (most recent call last):
File "/home/odoo/src/odoo/master/addons/purchase/tests/test_purchase.py", line 268, in test_with_different_uom
po_line.product_uom = uom_dozens
File "/home/odoo/src/odoo/master/odoo/tests/common.py", line 2179, in __setattr__
assert not self._get_modifier(field, 'invisible'), \
AssertionError: can't write on invisible field product_uom
```
closesodoo/odoo#95841
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
With recent commit[1], we now use the wowlEnv instead of the legacy one,
and use the service provided by env to call the rpc.
This was adapted in the activity model, but not on the patched method
under calendar.
This commit fixes the issues to adpat the change, and so the 'Reschedule'
button for the meeting activity now opens the calendar view as expected.
Apart from that, this commit also tries to align this button with other
activity buttons, for better UI.
commit[1] - https://github.com/odoo/odoo/commit/3573a7fef497d
taskID-2899402
closesodoo/odoo#95747
X-original-commit: b7efe2a80f9da175114cf1138565580981690001
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Purpose
=======
Improve the usability of the outlook modules. Lessen module complexity.
Specifications
==============
Remove the checkbox "Use Outlook" and instead use the
smtp_authentication and the server_type, to be consistent with Gmail.
Hide the password field for Outlook / Gmail mail servers.
Add constraints on the outgoing mail server to force the user to use
the right configuration (e.g. the from_filter, so the sending do not
fail).
Merge fetchmail_{google/microsoft} into google_gmail / microsoft_outlook?
Most of the time, both module will be installed at the same time, or
none. For that reason, we want to merge both modules, for both
providers, to lessen complexity.
Task-2811567
closesodoo/odoo#88215
Related: odoo/upgrade#3419
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Most of the time, both module will be installed at the same time, or
none. For that reason, we want to merge both modules into Microsoft Outlook.
Task-2811567
Part-of: odoo/odoo#88215
Purpose
=======
Most of the time, both module will be installed at the same time, or
none. For that reason, we want to merge both modules into Google Gmail.
Task-2811567
Part-of: odoo/odoo#88215
* fetchmail, google_gmail, fetchmail_gmail
Purpose
=======
Improve the usability of the outlook modules.
Specifications
==============
Remove the checkbox "Use Outlook" and instead use the
smtp_authentication and the server_type, to be consistent with Gmail.
Hide the password field for Outlook / Gmail mail servers.
Add constraints on the outgoing mail server to force the user to use
the right configuration (e.g. the from_filter, so the sending does not
fail).
Add an option in the mail module to install Outlook.
Show a message for the outgoing mail servers to explain each
authentication methods.
Task-2811567
Part-of: odoo/odoo#88215
Purpose
=======
If we want to deploy Outlook for a custom organization, it might be
useful to be able to customize the endpoint used in the API request.
For that purpose, we added a system parameter to overwrite the default
endpoint.
Task-2811567
Part-of: odoo/odoo#88215
Purpose
=======
Improve the incoming mail server list view and the outgoing form view.
Show the most used option first, and make the view more responsive.
Task-2811567
Part-of: odoo/odoo#88215
Prior to this commit, the `sale_timesheet_tour` was indeterministically failing
due to the fact that the tour step responsible of saving the data was not waiting
for the previous step (responsible to confirm the SO) to be finished.
This commit fixes this issue by ensuring that the buttons that allow confirming
the SO are not visible any more.
closesodoo/odoo#95825
X-original-commit: 287a7449ed5c809847a6b0c9719b8b3cc0215e3a
Signed-off-by: Xavier <xbo@odoo.com>
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Deprecated method _get_default_invoice_date is no longer used and can therefore be safely removed.
closesodoo/odoo#95820
Signed-off-by: William André (wan) <wan@odoo.com>
As several customers complained about lot of bugs in microsoft_calendar in 14.0,
It has been decided to backport bug fixes of the model layer from master to 14.0,
without the need of an upgrade script (no new field, ...).
In master, we use 2 ids (organizer event id + universal id) instead of only one,
to handle Odoo <-> Outlook sync correctly when several attendees sync their Outlook
calendar with their Odoo calendar. For that, we have added a new field.
To report this bug fix in 14.0, the existing field which stores the organizer event id,
is now a string storing both ids separated by a ':' as follow: 'organizer_event_id:universal_id'.
2 new compute fields have been added to be able to use these 2 ids more easily.
(all commits from the original PR have been squashed to ease forward-port)
closesodoo/odoo#95736
X-original-commit: 5e83318a7240585371efd31e407829793f3e732f
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
If the test is ran on a database without account installed, it will fail
because of the missing ref.
closesodoo/odoo#95735
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
During Editor initialisation, detect if the editable element contain orphan inline nodes.
If so we transform the base element HTML to put those orphans inside `<p>` containers.
This is used to ensure the HTML generated by Etherpad is compatible with this editor,
allowing the user to use all the features without loosing the Etherpad look.
task-2877273
closesodoo/odoo#93207closesodoo/odoo#95347
Related: odoo/enterprise#28965
Related: odoo/enterprise#29130
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
# Conflicts:
# addons/web_editor/static/lib/odoo-editor/src/OdooEditor.js
closesodoo/odoo#95445
Related: odoo/enterprise#29185
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
During paste HTML, an inline element or a textNode should never be
inserted outside of the targeted initial container.
Those kind of orphans elements should never be present in an HTML paste data,
but better safe than sorry.
Part-of: odoo/odoo#95347
# Conflicts:
# addons/web_editor/static/lib/odoo-editor/src/OdooEditor.js
Part-of: odoo/odoo#95445
* Adapt Unit tests to always have a container block element
* Add some tests to ensure the editable root direct child nodes are all blocks
* Fix paste HTML unit tests to properly check that we never paste inline
elements or text nodes outside the target container
Part-of: odoo/odoo#95347
# Conflicts:
# addons/web_editor/static/lib/odoo-editor/test/spec/collab.test.js
# addons/web_editor/static/lib/odoo-editor/test/spec/copyPaste.test.js
# addons/web_editor/static/lib/odoo-editor/test/spec/editor.test.js
Part-of: odoo/odoo#95445
Valentin Chevalier