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>
The component ExpressionEditorFieldSelector used by the expression editor
to allow the selection of a field has several drawbacks:
- the fields are not alphabetically ordered
- there is no possibility to (fuzzy search) a field
- the field types are not indicated in debug mode.
- the style is different from the classical style to be found in the
domain selector.
Here we make the expression editor use a version of the ModelFieldSelector
component where the debug input is not shown. Indeed, this would require
some validation of the input value in order to prevent complex path like
user_id.company_id that are forbidden in studio for instance. Anyway,
there is not real need for such an input since it is easy to find/select
a simple path with the fuzzy search.
Task ID: 3599699
Part-of: odoo/odoo#142483
This RPC /mail/thread/data is called on every
form view change, even when not saved.
It comes from the chatter onWillUpdateProps
and calling `load` then `fetchData`
We don't want to reload chatter when every time props updates.
Do it when the record `onWillLoadRoot`
closesodoo/odoo#140662
Task: 3569123
Related: odoo/enterprise#50607
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce:
- Go to website (in "Edit" mode) > Drop a new popup snippet > Make it
visible on all pages ("Show On" = "All Pages") > Save.
- Add a new language (e.g. fr) > Try to translate the page > A warning
is displayed: "Action 'get_page_option' was not able to be handled."
- Try to save > The "save" button just keeps loading and the same
warning is displayed again.
Now let's try to do the following actions [1]:
- Go to website (in "Edit" mode) > Drop a countdown snippet in the
footer > Set a conditional visibility on it (e.g. "Visibility" =
"Conditionally" = "Visible for Logged In") > Save.
- Try to translate the page > Save > We get the same error described
above.
Technical details:
Starting from [2], user has the possibility to translate invisible
blocks by allowing `_updateInvisibleDOM()` in "Translate" mode, which
makes them accessible in the edit bar.
In the case of an "All page" popup (The snippet is moved to the
`<footer/>` element to make it available on all pages...), the snippet
editor will be created with the parent's one (`<footer/>` in this
case) leading to the following behaviour when saving the page content
in "Translate" mode:
A- `cleanForSave()` called for all snippets...
B- `toggleTargetVisibility()` is then called for the `<footer/>` (which
doesn't have a `o_snippet_invisible` class).
C- `onTargetShow()` is consequently called allowing `_isShown()` to
check the footer visibility via the `get_page_option` action.
Since the navbar action widget (`ContentMenu` in this case) that handles
the action is not available in "Translate" mode, the action demand will
be aborted and we get the warning above.
Implemented solution:
- In "Edit" mode (for `s_popup` snippets):
The initial goal of this commit was to fix this behaviour by excluding
the parents when creation the `s_popup` editor in "Translate" mode.
But after some discussion, we prevent this behaviour for all `s_popup`
snippets (even in "Edit" mode) since they should not display their
parents options.
- In "Translate" mode (for all invisible snippets):
As described in [1], the issue will always occur if an invisible element
enables a parent option that needs action handers... And since we only
need to hide / display invisible elements to translate them, we also
prevent creating parents editors in "Translate" mode.
[2]: https://github.com/odoo/odoo/commit/04409af0571ed763c5712dbf857ea7dda81b2374
opw-3485565
closesodoo/odoo#143269
X-original-commit: 33e5bc36ecb5a4316ad7a61380461cb1663cb38a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
The try-except ensures `reward_id` is either an `int` or `None`, calling
`int` on it again doesn't do anything but risk throwing a `TypeError` if
`reward_id` was set to `None`.
closesodoo/odoo#143256
X-original-commit: fed6c4499b1a32aaeb8e7aeb1d89b3a27a8f8c73
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Levi Siuzdak <sile@odoo.com>
Versions:
---------
- saas-16.3+
Steps to Reproduce:
-------------------
1. go to Sales / Products / Discount & Loyalty;
2. go to 10% Discount Coupons;
3. click on Generate Coupons;
4. generate for Selected Customers (yourself);
5. repeat to get a second coupon;
6. go to webshop and try to buy something;
7. at checkout, try to apply the first coupon.
Issue:
------
Clicking the coupon's "Use" button doesn't seem to do anything.
Cause:
------
The `claim_reward` method iterates over all potential coupons, always
selecting the last, most recent one, only to reject it if the code
doesn't match the coupon selected by the user.
Solution:
---------
Return as soon as a matching coupon is found.
opw-3562615
X-original-commit: 17d3862b27a5d388f37566d77a1790ef1b319589
Part-of: odoo/odoo#143256
Current behavior:
If a product had a sales description, it was displayed in the order
when settling it from a sale order. But only the name should be
displayed in the PoS.
Steps to reproduce:
- Create a product with a sales description
- Create a sale order with this product
- Go to the PoS and settle the order from the sale order
- The name of the product is name + sales description instead of just
the name.
opw-3547814
closesodoo/odoo#143241
X-original-commit: 2afb8dc80eccb2ba6c9d20982f0e869f5bde2397
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Before the windows image couldn't run because the module
websocket-client was missing, now it's added in the list of module to
install on windows
closesodoo/odoo#143205
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
When the user creates a new article in Knowledge using a template, the
system shows a dialog indicating that there is a conflict between the
client and the server. This commit will ensure that the conflict dialog
won't show up when the document does not have any versioning yet.
Steps to reproduce the issue:
1. Go on Knowledge
2. Open the editor
3. Click on the "Browse Template" button
4. Choose a template
5. Click on the "Load Template" button
Justification
---
When the editor is started, the system generates a new snapshot with ids
generated randomly (see: constructor of `OdooEditor`, `historyReset`,
`_historyGetSnapshotStep`).
When checking if the document is "stale" (i.e: out of sync), the system
verifies the existence of a history step with the id specified in the
`data-last-history-steps` attribute of the first node of the document
(see: `_isLastDocumentStale`). If such a history step does not exist,
the client document is considered "stale" and will be discarded. The
`data-last-history-steps` attribute is set by the last writer when
saving the document.
When creating an article from a template, the server generates a new
record and copies the template's body in the article's body. The system
does not set any `data-last-history-steps` in the document. As a result,
the document will be considered "stale" when opening the article and a
conflict dialog will warn the user that the current document will be
discarded.
This commit will update the `_isLastDocumentStale` function to ensure
that a document that has not been versioned yet won't be considered as
"stale". The `data-last-history-steps` attribute will then be set when
the user opens the article and save it.
task-3587990
closesodoo/odoo#143194
X-original-commit: 69e7694580ae20bb21de1316de5aa770e7ed8eed
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Signed-off-by: Julien Banken (jbn) <jbn@odoo.com>
When there was no product in 'Gift Card Products' every
product was generating product equal to it's value.
Now when there is no product specified, no product will generate
gift card.
opw-3415384
closesodoo/odoo#143270
X-original-commit: 3d64ab7cc54a8bb69f98885fd037b2d48b1c2c29
Signed-off-by: anko-odoo <anko@odoo.com>
Commit [1] introduces a stronger regex for url containing symbols. It did so by
using a negative lookbehind, which was not supported on some version of Safari
iOS and edge. Later commit [2] was introduced in attempt to reproduce the same
behaviour without using negative lookbehind but missed some cases such as github
compare link where the url had multiple symbols.
This commit is an attempt to reproduce the same behaviour like [1] while
improving [2].
[1]: a42a19e
[2]: ff99e45
task-3468646
closesodoo/odoo#143250
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Before this commit:
There were certain issues with the URL regex, wherein it failed to validate
against domain list under certain circumstances involving URLs with two dots.
for eg. this.document.anything
After this commit:
The URL regex is modified to ensure that if a URL regex does not ends with
the domains in tldWhiteList, it must start with http://, https://, www. or
if it does not start with http://, https://, www., it must end with a
domain from the tldWhiteList.
task-3468646
Part-of: odoo/odoo#143250
In pickings we "pick", in mrp we "consume", so let's make the warning
message consistent even if it is probably still confusing.
closesodoo/odoo#142933
Related: odoo/enterprise#51171
Signed-off-by: Steve Van Essche <svs@odoo.com>
During previous fix: odoo/odoo#141797, the `not move.picked` check was
moved to earlier in the if statement to avoid unnecessarily looping
through the move lines, but the ( was forgotten to be moved with it.
Since we don't want to force all manual consumption marked moves to have
a lot_id, let's move the (.
Part-of: odoo/odoo#142933
Original requirement:
On the return slip, the 2 barcodes are too close to each other.
So, it's too easy to scan the wrong barcode. We should add a bit
more space between the 2 barcodes (For the demo, I had to take
another document for managing the scanning)
closesodoo/odoo#142916
Signed-off-by: Steve Van Essche <svs@odoo.com>
In Fattura Semplificata, 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.)
related PR: odoo/odoo#143122
opw-3597050
closesodoo/odoo#143240
X-original-commit: 2a9344e08edb935f29489286029a75d3d236adb0
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Correct the wording of "Visa Expire Date" to "Visa Expiration Date"
for the visa_expire field to be more grammatically correct.
task-3595978
closesodoo/odoo#143222
X-original-commit: 1722e62193d0b587e508d30b1d460498c1ea4c86
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Signed-off-by: Florent Maisse (mafl) <mafl@odoo.com>
lejeune quentin