The following situation happened with module industry_fsm, when trying
to delete a cancelled sales order corresponding to a task. When doing
so, the server crashes with error "Could not find all values of X to
flush them", which means that a dirty field (pending update) has lost
its value from cache.
The issue is related to recursive computed fields. Before deleting a
record, method unlink() invokes modified(), which determines all the
fields that depend on the record to be deleted, and marks them to
recompute. Those fields should be recomputed after the record is
deleted, and not before. We found out that the recursive call to
modified() made for recursive fields can force the recomputation of the
recursive field itself before the record is deleted, which causes
unlink() to crash.
The fix consists in marking the fields for recomputation at the very end
of method modified(), after all the fields to recompute have been
determined. This ensures that the processing of recursive fields always
uses the current value of the field instead of its recomputed value.
X-original-commit: 1f5293bc63ae7b06fd0df8d509dc7fafaa016a22
Part-of: odoo/odoo#143644
Since odoo/odoo@b3a2fb51bc, it is not possible to use partial
points rewards. However this commit only fixes the behavior for loyalty
cards, where it should be applied to many other program types.
closesodoo/odoo#143643
X-original-commit: 64ebec5c7db88c247f3dafbeecbd2ae2b9ee4238
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
* product_configurator, comparison, stock(_wishlist)
Before this commit, the option "Prevent Sale of Zero Price Product"
would still allow some free products to be added to the cart (accessory,
optional and alternative products).
This commit makes sure no free product can be added to cart if this
option is activated.
Also, this option was conflicting with some other options and not well
handled in bridge modules. This commit improves the UX when this option
is activated.
task-2983615
closesodoo/odoo#143626
X-original-commit: 158f622f00bad7f3b24b81cfa715601f5ff7022a
Part-of: odoo/odoo#143504
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
During upgrade, it try to create picking type if not exist
like pos type and everytime will create new sequence too
for that picking type. during the creation of picking type
there is python constraints that raised if
same sequence name with same company exist.
so to avoid that will check before creating new sequence
if already same company sequence exist then update the
sequence name with id using copy prefix to easily identify
as copy name.
closesodoo/odoo#143609
X-original-commit: e16c15b5306f841d8da6ec3e951aff606e377134
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Accounting > Reporting > Invoice Analysis
Open Pivot View
Collapse column group, expand by Date>Month
StopInteration traceback will raise
line: column = self._read_group_postprocess_aggregate(spec, next(column_iterator))
The error is caused by a missing interval attribute on the group by
pivot view default search.
This will make the view call `read_group` with a wrong groupby list
['invoice_date', 'invoice_date:month'], that will cause the error raise
opw-3603433
closesodoo/odoo#143595
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Since the module loader rewrite, it now reports errors directly in the
DOM. The error alert also has the class "modal" so that in case a tour
comes accross a page with module loading errors, it will only look for
elements inside it and fail. But in the QUnit test suite, modals are
invisible by default, causing the page to be blank in those cases.
This commit adds a css rule to make sure that this error alert is shown,
and updates the code that was previously used to report these errors in
the qunit suite to instead simply check for errors reported by the
module loader.
closesodoo/odoo#143589
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Issue:
======
When we have a product as a free product reward in cart and we want to
add the same product from the shop nothing will happen and the cart
stays the same.
Steps to reproduce the issue:
=============================
- Create a loyalty program with the following options:
type: pormotions
rule: minimum quantity :1 , gran 1, minimum purchase 0, per order,
product: select anyone
reward: type : free product , quantity rewarded : 1, product : select
any other product
- Go to website and add the product from the rule to cart
- Go to cart and claim reward
- Go back to shop and add the product from the reward to cart
- Go to cart
- The cart stays the same
Issue:
======
When searching for the `line` it doesn't consider if the line is a
reward or not.
Solution:
=========
We filter the reward lines if `line_id=False`
opw-3550585
closesodoo/odoo#143581
X-original-commit: 2b97bb83b312f553d3ec1b6e96a74c744955aed6
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Issue:
======
When we settle an order that has a product with uom not pos_groupable
and quantity isn't an integer for example 3.5 it will add 4 lines each
with quantity = 1 which is not correct.
Steps to reproduce the issue:
=============================
- Create a product with a not pos_groupable uom (kg for example)
- Create a sale order with that prouct and add a not integer quantity
- Go to pos and settle the order
- You will have 4 lines added each with quantity = 1
Origin of the issue:
====================
The quantity was hardcoded = 1
Solution:
=========
I addeed order lines equal to the integer part of quantity and one last
order line that have the rest quantity.
opw-3579225
closesodoo/odoo#143566
X-original-commit: 3db0515959861e65f05b572d4827692ed00a1925
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
If the format set on a partner does not work for our peppol implementation, `enable_peppol` should be `False` and the checkbox should be hidden.
This commit checks invalid partners when computing `enable_peppol` on account_move_send wizard.
Since we hide the checkbox in this case, we don't need to show the peppol warning when opening send&print to such partners.
closesodoo/odoo#143565
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Update participant status every 6 hours instead of once a day. Once a day is too slow for users and it looks like as if something went wrong.
Part-of: odoo/odoo#143565
The additional lines originating from the product configurator are
sometimes not well handled by the framework. With this additional steps
in the test, we ensure the line remains after selecting it without
editing anything, a case that was broken several times already.
closesodoo/odoo#143554
X-original-commit: ce9251badd8cc01edfb2f83fd192f7328d48e7f0
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
Before this commit when you unlink a sale.order.line the field carrier_id of sale.order is set False for each delivery line.
This commit prevent also serialisation failure on ecommerce.
closesodoo/odoo#143533
X-original-commit: c9fe8d113deb8103ad531d999f75f74c5475f46e
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: vava-odoo <112173839+vava-odoo@users.noreply.github.com>
Suggestions can now be accessed by entering a GST number in the Tax
ID field of the contact form.
Add the option of allowing completion even with an 'insufficient
credit' error.
closesodoo/odoo#143532
X-original-commit: 2e47f94eba7a6c9df278c887f879fffeb8552706
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
Task Adhoc: 29838
Description of the issue/feature this PR addresses:
-It is needed to improve the filters and and "Group By" from the search view of own checks and third party checks.
* In "Accounting/Vendors/Own Checks" it is needed to:
1) Remove the filter "Checks on hand".
2) Remove from "Group By" the group "Third party check Current Journal".
* In "Accounting/Customers/Third Party Checks" it is needed to:
1) Add the filter "Checks on hand".
2) Add in "Group By" the group "Third party check Current Journal".
3) Remove the filter "No Bank Matching".
4) Rename filter "Third party check Current Journal" to "Current Journal".
- When a payment is created is needed show the updated search view "Accounting/Customers/Third Party Checks" when searching more checks if "Existing Third Party Checks" payment method is selected.
- Change spanish translate of "Third Party Checks" group "Third party check Current Journal" from search view from "Actual Diario de Cheques de Terceros" to "Diario de Pago".
- Translate to spanish the filter "No Bank Matching" to "No conciliado con banco" and update other translations to spanish.
Current behavior before PR:
* In "Accounting/Vendors/Own Checks" in the search view:
Exists the filter "Checks on hand" and exists the group "Third party check Current Journal" in the "Group by".
* In "Accounting/Customers/Third Party Checks" in the search view:
Don`t exist the filter "Checks on hand". Don`t exist the group "Third party check Current Journal" in the "Group by". Exists the filter "No Bank Matching". There is a filter named "Third party check Current Journal".
* When a vendor payment is created when searching more checks if "Existing Third Party Checks" payment method is selected then is showing the same search view as "Accounting/Customers/Third Party Checks".
* Spanish translate of "Third Party Checks" group "Third party check Current Journal" from search view is "Actual Diario de Cheques de Terceros".
Desired behavior after PR is merged:
* In "Accounting/Vendors/Own Checks" in the search view:
Not exists the filter "Checks on hand" and not exists the group "Third party check Current Journal" in the "Group by".
* In "Accounting/Customers/Third Party Checks" in the search view:
Exists the filter "Checks on hand". Exists the group "Third party check Current Journal" in the "Group by". Not exists the filter "No Bank Matching". There is not existing a filter named "Third party check Current Journal".
* When a vendor payment is created when searching more checks if "Existing Third Party Checks" payment method is selected them is showing the updated search view as "Accounting/Customers/Third Party Checks".
* Spanish translate of "Third Party Checks" group "Third party check Current Journal" from search view is "Diario de Pago".
Video:
https://drive.google.com/file/d/1H1ng4mPsN0sf1NwW_JMOmZrhe8TrrBlk/viewclosesodoo/odoo#143526
X-original-commit: c56c35eb9b161dc5bdeaa545b1ed4e9e2a093a44
Signed-off-by: Josse Colpaert <jco@odoo.com>
From odoo 16.4 we need run odoo with python >= 3.10
However Debian Bullseye can't run python > 3.9.2 from apt manager
Now we use Debian Bookworm with python 3.11
closesodoo/odoo#143517
Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
Add Viva Wallet to the POS.
A new payment method that allows payment in person via Smartphone
closesodoo/odoo#140353
Task: 2991908
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
This commit removes an unnecessary field validation for HTML field.
closesodoo/odoo#143307
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Nicolas Danhier (nda) <nda@odoo.com>
During an onchange, fields read from database are validated again. This causes
an infinite loop with HTML fields since Odoo 16 because we're revalidating a
value we're reading from the database, which triggers a sanitisation check,
which fetches the original value, etc etc.
Even if the functional bug only appears in 16.0 and above, the root cause is
also present in 15.0 so this commit targets 15.0
steps to reproduce (in 16 or next versions):
- Change Marc Demos's access rights Website = Restricted Editor
- Bypass HTML Field Sanitize = Off
- Inventory / Products / Product Variants
- Studio on the Sales tab and add website_description under Website Sequence
- Go to product [E-COM07] Large Cabinet and fill in the newly added website description
- Log out and log in as marc demo
- Navigate back to [E-COM07] Large Cabinet product variant and try to re-order the vendors on the purchase tab
- Error
before this commit:
Error (infinite loop) during onchange
File "/home/nda/dev/odoo/16.0/odoo/odoo/models.py", line 6489, in onchange
record[parent_name]._update_cache({name: record[name]})
File "/home/nda/dev/odoo/16.0/odoo/odoo/models.py", line 5310, in _update_cache
value = field.convert_to_cache(value, self, validate)
File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 1977, in convert_to_cache
return self._convert(value, record, validate)
File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 2000, in _convert
original_value = record[self.name]
File "/home/nda/dev/odoo/16.0/odoo/odoo/models.py", line 5897, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 1198, in __get__
value = self.convert_to_cache(record._origin[self.name], record)
File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 1977, in convert_to_cache
return self._convert(value, record, validate)
File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 2000, in _convert
original_value = record[self.name]
...
after this commit:
no error
opw-3575865
X-original-commit: 24d804e
Part-of: odoo/odoo#143307
The issue is that "load older" was called every time the thread was made
visible, in particular after chat window unfold.
The load more button will naturally be visible when first loading a
thread, it only makes sense to check its final visibility and not
intermediate steps.
But there was a bug where the loading mechanism was relying on the
initial "load older" to fetch messages, because the messaging menu
preview was incorrectly setting the thread as already loaded, when it
just fetched the last message.
Moreover, the "last message" displayed in the preview was not correctly
computed, and it could end up being the last "currently fetched" message
and not the last of all messages (when jumping in the past), and it
could also be a non-persistent message.
runbot-35533
closesodoo/odoo#143129
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
We should only mark account moves as "Peppol ready" if it's a customer invoice/customer credit note.
These are also the only types of account moves we should display when a user wants to filter by "peppol ready" as this means they want to easily select all and send them via peppol in batch.
This commit limits "Peppol Ready" to `out_invoice`, `out_refund`, `out_receipt`.
task-3603416
closesodoo/odoo#142688
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Users need a helpful message for selecting the right EAS and Endpoint numbers.
In Belgium it should always be 0208 according to BOSA,
so we can display a warning message advising them to select that code for Belgian partners.
Part-of: odoo/odoo#142688
Steps to reproduce:
-------------------
- create an invoice without confirm it;
- go to the preview and download it;
Issue:
------
A traceback appears.
Cause:
------
We try to get `ids` field of a non "record" object.
Solution:
---------
Make sure you are in the case of an invoice
that is `posted` to download a pdf.
sentry-4612532780
closesodoo/odoo#141640
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Co-authored-by: adwid <awt@odoo.com>
PR [1] removed the legacy error handler that swallowed promise
rejection errors with anything else than an error (namely, the
"legacyRejectPromiseHandler"). As a consequence, promise rejections
done as "control flow" now lead to error dialogs being displayed.
In particular, it happened on the website (with website_event_track
installed), if the browser doesn't support service workers.
This commit simply leaves the promise pending if the feature is
unavailable.
[1] https://github.com/odoo/odoo/pull/137702closesodoo/odoo#143516
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Previously, the datetime field read the value for readonly directly in
the attrs when extracting its props when available. This resulted in 2
separate bugs:
- in debug mode, props validation of the datetime picker would fail, as
it expects to receive a boolean for the `range` prop. This was caused
by the fact that required was the raw attribute (a string) instead of
the boolean and ended up being propagated to the `range` prop
- outside of debug mode, the value for required did not cause a crash
but any value for required that was not empty would be interpreted as
truthy, causing the field to always be display itself as though it is
required. In non-range mode, this is invisible, but in range mode, it
would always show the second datetime input and the arrow between the
beginning and end date, even with required being 0/False, or a python
expression that may evaluate to false
This commit fixes that by instead reading the value for required from
the dynamic infos provided to `extractProps`, which will always be a
boolean and contain the value of the evaluated expression when
appropriate.
closesodoo/odoo#143509
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
There's currently no way to move a dashboard from a section to another
You have to start again from a blank dashboard in the other group.
closesodoo/odoo#143505
Task: 3592986
X-original-commit: f7ba25afd5f1332b21a3d1631020ad9cd4b116fc
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
When users edit an outbound/inbound payment method line of their bank
journal and at the same time remove another payment method line,
the edited line changes back to its initial state (without the change).
It was caused by a complicated way to know which payment
method lines are available for this journal. This non-stored compute
field is recomputed for each change made on the inbound/outbound
payment method lines. It means that the function deals with the
origin record instead of the record itself.
During the search for this fix, we found out that everything works
fine if we remove the column_invisible on this computed field. In
that case, we did not have so as many calls to the compute function
to get the values. It's obviously not a solution and that's
why after some investigation, we decided to use the _origin id
when we get the outbound/inbound_payment_method_line in the
_compute_available_payment_method_ids function.
Thanks to @h4818 for his help during the process.
opw-3597536
closesodoo/odoo#143492
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Co-authored-by: Habib Ayob (ayh) <ayh@odoo.com>
The language was added at dccc8f39d0
419.png as odoo thinks it's a country...
closesodoo/odoo#143439
X-original-commit: 3bb58958c8f5f98da21bdac411bd226d03e1591b
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When performing a manual stock revaluation, the value difference is distributed
equally among the available stock. This method breaks down however in case of a
devaluation where some items in stock are already valued less than the unit
cost difference: this results in a negative value.
This commit will prevent such devaluations by raising a UserError whenever the
remaining value of a stock.valuation.layer becomes negative. Additionally, after
a revaluation, the standard_price field will now also be updated for fifo valued
products.
opw-3340298
closesodoo/odoo#143437
X-original-commit: a6db4b48f1d32f1020ee3ad242c77211aa10b3b2
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
- Open a record with the chatter (a task for instance);
- Zoom your browser until the chatter is inline with the task (as it is
the case on mobile)
- Write a big message.
Before this commit, the composer takes all the allowed place on the
screen, and we cannot see or scroll-down to the older messages.
Now, the behavior is the same as is done in mobile, the composer stays
sticky, but it will not take all the allowed place, and leave place to
see and scroll-down the older messages.
opw-3593032
closesodoo/odoo#143427
X-original-commit: 26e8c0a74b9f0adb728c1d76ec7f45ec12623f6c
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
- Since dd21c708cc08d484530bc7c8433ebbb79f59323a, the opening cash difference is not posted in the suspense account. This commit fixes that.
- Removes the error preventing the deletion of cash difference journal entries.
task-id: 3460173
closesodoo/odoo#139975
X-original-commit: 52681b588c8353721f0b3d40f1b013bf0fc23904
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Purpose
========
Update demo data to better show what Appointment can do.
Specification
==============
Changing the capacity of some tables.
Tables 1-4 => from 4 to 2.
Tables 9-11 => from 4 to 6.
Task-3496910
closesodoo/odoo#137673
Related: odoo/enterprise#48438
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
Issue:
When user add sub task then first field is focused.
Fixed:
In this commit, we have made the title the default focus so that the user does not
have to click manually and time will also be saved.
Steps:
- Install project app
- Active Task Dependencies
- Create task and add subtask
task-3471102
closesodoo/odoo#143251
X-original-commit: 487a62a249e783ca15f95675a6cf43322b61d569
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In this commit, we fix the last step of the PosSettleOrderNotGroupable tour
which is deterministically failing in runbot.
closesodoo/odoo#143229
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Steps to reproduce:
- create an order with a combo product
- change the customer to a customer that has a custom pricelist
Bug:
Each combo orderline will be recalculated independently
Fix:
Extract the combolines price calculation from addComboLines. Modify the
setPricelist method to use the new price calculation method for the
combolines.
closesodoo/odoo#143168
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
The aim of this commit is handling the invoice payment terms
in the oioubl xml file.
closesodoo/odoo#142501
Task-id: 3422407
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Before this commit, the payment button was part of the checkout/manage
form widgets, which caused conflicts when other modules needed to
enable/disable the button depending on custom conditions.
After this commit, the payment button logic is extracted in a separate
widget that handles its enabling after checking if all conditions are
satisfied. Other modules can extend the widget and override
`isButtonReady` to add custom logic.
task-3568861
closesodoo/odoo#142265
X-original-commit: 496c22f67b840a72758640576546ba16b177aafc
Related: odoo/enterprise#50783
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
In the recent redesign of the `website_event` module(s)
[1] a field was used in the templates of event_track
that only exists if event_track_live is installed.
The `t-att-class` argument is now overriden in `event_track_live`.
task-3597612
1: 94c5bc3d152c80fdbb6798d9b4d28bf62740856b
closesodoo/odoo#142215
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
To reproduce
============
having a special character in url like `à` (it's possible)
try to print an invoice, a weird character is printed next to currency symbol
Problem
=======
Apparently the method responsible of converting from string to html
analyzes the few first characters to determine the encoding,
so having the base url in the beginning with its special character
leads to wrong encoding.
Solution
========
convert using html parser with unicode encoding
opw-3415418
closesodoo/odoo#143462
X-original-commit: b1cf2a209230b4ace817ff51ab5f55f19b586b11
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
Step to reproduce the issue:
1) Install l10n_eg and l10n_eg_edi_eta modules and select the company EG Company
2) Configure all required fields to post an Invoice with an Egyptian company (wrong credentials are ok since the issue can be triggered without really sending the e-invoice)
3) Create an invoice with an invoice line that has a quantity of 12 and a price unit of 12.8 with a 100% discount
4) Post the invoice
5) open the created json document in the 'EDI Documents' tab
Result: The 'salesTotal' field has a value of 153.60000000000002, causing the E-invoice rejection by the authorities
Expected result: 153.6
opw-3569383
closesodoo/odoo#143463
X-original-commit: bb9a5137c292c5c84ac8df1cd6a64106375286a5
Signed-off-by: Josse Colpaert <jco@odoo.com>
When an Italian e-invoice is generated, it will include DDT sequence of
DDT stock moves. If those stock moves have picking type different of
'outgoing' (eg: Dropshipping), the picking type does not have DDT
sequence leading to a traceback.
Now we only consider DDT stock moves if they have the outgoing picking type.
Steps to reproduce:
- Create local database
- Install accounting, purchase, l10n_it_stock_ddt
- Switch to Italian company
- Activate dropshipping in settings
- Put Fattura Elettronica mode in "test" in settings ("demo" mode should be fine to)
- Create a a storable dropship product
- Create a sale order with dropship product and confirm it
- Click on purchase smart button and confirm purchase
- Validate to dropship transfer
- Create invoice from SO and confirm it (should get the DDT smart button)
- Click "Process now" on top of invoice => Traceback
opw-3544775
closesodoo/odoo#143461
X-original-commit: 27541b1e9b80db5234aff3a2591d1eb1ce9629a0
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Currently, a chat window is folded when hidden and the server is
notified. This is incorrect and leads to useless rpc calls/undesirable
fold state. A chat window is only hidden when space is lacking to display
them all. Only a user interaction should be able to fold a chat window.
Since folding the chat window when hidden is an implementation detail
only used to show the chat window header in the hidden windows dropdown,
this PR removes this behavior and adapt the hidden windows menu to
achieve the same result.
Steps to reproduce the issue:
- Go to Odoo, resize your browser so that it can only fit 2 chat windows.
- Open two chat windows, server is notified twice: so far so good.
- Open another chat window: server is notified twice: this is not correct,
the server should only be notified of the newly opened chat window.
- Reload the page: the server is notified once for each window not fitting
in the screen, this is incorrect as well.
task-3600480
closesodoo/odoo#143438
X-original-commit: 27f09bfc5049b1350b7e940a7beef92f63799771
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Steps to reproduce:
1- Install CRM app
2- Go to pipeline and create a new lead
3- Write a name for contact and click on 'Create and edit...'
4- Choose 'individual' as contact type and select the company related to this individual
5- the address will remain empty and will not be auto populated
Current behavior before PR:
The address is not auto populating when creating a new individual contact through a new lead. This happens because when you choose the contact type to individual the address type is not chosen so it is not populating any of the addresses
Desired behavior after PR is merged:
The address is now auto populating as I am passing to the form a default value for the contact type which is 'Contact' which is the default value when you create a contact from Contacts app
opw-3569833
closesodoo/odoo#143408
X-original-commit: ae51afafc606e5ca568864fdf04a0ea618bf242d
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
Steps:
- Install `website_sale`
- Enable demo payment provider
- Set a positive delivery fixed price
- Go to /shop, add a product and checkout
- Error "The cart has been updated, Please refresh the page"
Because amount in kwargs in `shop_payment_transaction` was compared to
`amount_total`to check the order but `amount_total` doesn't contains
delivery cost unlike `amount`
closesodoo/odoo#143404
X-original-commit: e79a35df5a62114d292c4357fe3e047c156d179b
Signed-off-by: Achraf Ben Azzouz (abz) <abz@odoo.com>
Steps to reproduce:
- Create a BoM with a single component
- Create a MO using that bom and confirm it
- Set more consumed components than planned and validate the MO
- Open the overview
Issue:
While the overview correctly displays the used quantity, the real cost
column still uses the initial demand to compute its costs instead of the
quantity used.
closesodoo/odoo#143401
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Currently, discuss push-to-talk only works when the browser has focus
because key events are not fired otherwise.
This commit adds an extension for chromium-based browsers that allows
to register a system-wide push-to-talk shortcut and adapts the rtc
service in order to listen to the extension events.
closesodoo/odoo#140752
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Copy-paste mistake in the template after refactoring.
IDCodice for the Sender has to be filled with the CodiceFiscale
and not with the VAT number.
(We only use VAT number if we don't find the CodiceFiscale.)
opw-3597050
closesodoo/odoo#143193
X-original-commit: 0c85e24a71442d0c0a717ee6264940047db1bdea
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
This issue arises when attempting to edit the job location field for a remote
job or when there is no value in the job location, try to edit and save record.
Steps to produce :
- Install `website_hr_recruitment` module.
- Open a job position that has a remote job location or no value in the job
location.
- Open editor > Edit that field and save the record.
- Error will be generated.
Error: int() argument must be a string, a bytes-like object or a real number,
not 'NoneType'
This issue occurs because here
https://github.com/odoo/odoo/blob/5e0f5c98330ca1b5d0696c109c9e3a2050a6210c/addons/web_editor/models/ir_qweb.py#L215
it will get None and then when it will try to convert in int than error occurs.
after this commit user will not be able to edit the job location field.
sentry-4588277341
closesodoo/odoo#143065
X-original-commit: e8f1152daeef3d28a2f9e062e77e11303a26cef2
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Raphael Collet