When a page is reloaded with the chat bot, it sometimes restarts from
the beginning. This commit ensures the chatbot starts where it left
after a page reload.
closesodoo/odoo#146175
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit and since commit [1], it was possible to clone a page
in the page list view.
It shouldn't be the case, cloning a page lead to bad result: a page
with the same URL which is not shown in the page list view because pages
are filtered by URL to remove duplicates.
Cloning a page has always had to be done through the page properties >
"clone page" button. Doing it this way will ask the user for a new page
name (and so a new url). The page will then correctly be listed.
[1]: https://github.com/odoo/odoo/commit/3192051806e0da1276604a31ad818f8768105362
opw-3591738
closesodoo/odoo#146173
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Purpose:
- Changed the default value of 'Show In Preference' (is_public) field from true
to false for preventing the automatic publishing of mailing lists.
Task-3594678
closesodoo/odoo#144699
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
In this pr we remove the blank choice in the self-ordering mode select.
It's unnecessary and throws a validation error on saving settings.
Task 3599144
closesodoo/odoo#142351
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
When the pos was loading only a part of the products, the request should follow those rules order:
- product is a favorite
- product is a service
- product had stock moves soon
- product update
But this request didn't take into account consumables products and if there was no stock move,
the value was null and postgres consider null values first when ordering desc.
Now with that changes, the order is correctly set based on the rules above.
closesodoo/odoo#139981
X-original-commit: 35a9168a53bded7e13451f4b485443c1b419ea21
Signed-off-by: David Monnom (moda) <moda@odoo.com>
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Problem
---------
In most cases, default deferred accounts and journal need to be set up
for localizations. This is normally done in the enterprise report module
for that localization. However, in some cases, the localization does not
have special report formats. In such situation, a localization report
module that sets up very few default values for the data company is
defined. This is way overkill.
Objective
---------
Allow the community company template to have 'unknown fields' defined.
Doing so, allows for the default deferred accounts and journal to be
defined without entreprise module to exists. Currently, this raises an
error.
Solution
---------
In the pre-processing of the chart template values, we skip all the keys
in the company data that are not company fields.
We add a context value which, when True, revert that behavior back to
before this commit and checks that all fields in the company template
are actual company fields (this will be used in the standalone test for
l10n modules).
We also update the standalone test for l10n modules so that:
1. it reports errors in all l10n modules at once.
2. it uses the context value described above and checks that all fields
in the company chart template are correct company field.
closesodoo/odoo#138937
Related: odoo/enterprise#50305
Signed-off-by: William André (wan) <wan@odoo.com>
Currently, if you switch to a right-to-left language and open the POS,
the numpad will look like this:
3 2 1
6 5 4
9 8 7
The numpad should stay the same even in RTL languages:
1 2 3
4 5 6
7 8 9
opw-3623228
closesodoo/odoo#146181
X-original-commit: fb0ece3336f53cfba4e7ef9c59f4acbd292da45a
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Issue:
Invoice move lines' quantities reset to 1 on the second page when the
customer is changed after pagination.
Steps to Reproduce:
1. Create an invoice with over 40 move lines (requiring pagination).
2. Navigate to the second page of move lines and observe quantities.
3. Change the Partner (e.g., Azure -> My Company).
4. Save changes.
5. Notice that quantities on the second page are reset to 1.
Solution:
Identified the issue as stemming from the `flush_model` method, which is
called on creation and triggers re-computation. This process calls
the `compute` method for the quantity field, leading to an erroneous
reset of quantities to 1.
Modified the compute method to only reset values to 1 if they are
initially 0 or False, thereby resolving the issue of unwanted quantity
reset during pagination when customer details are updated.
opw-3483851
closesodoo/odoo#146136
X-original-commit: bb08a627528cd7402a16689c420f3013488e9a4d
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Mohamed Erradi (moer) <moer@odoo.com>
Previously, when updating and resending a snailmail through the chatter,
it would re-send every snailmail letters in the DB with an error.
This behaviour lead to users mistakenly sending dozens of unwanted
snailmails, expecting to re-send the one they were currently on.
This commit changes that by only sending the relevant letter(s).
closesodoo/odoo#146078
X-original-commit: 43a56e84919604608d12bf3d8528339733fc79d8
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
Signed-off-by: Solan Delvenne (sode) <sode@odoo.com>
Before this commit, when many channels were pinned in Discuss,
the messaging menu took a while to open and render all items.
This happens because `fetchPreviews()` and `inbox.fetchNewMessages()`
were inserting data for each thread and message. This meant computed
and sorted fields were called with that many objects.
This commit improves the performances by wrapping all of it in an
update cycle transaction, so that computed and sorted fields are
invoked only once at the end of the update cycle.
With `contacts` installed, populate `medium`:
- Before this commit: 1min.
- With this commit: 2sec. (30x faster)
closesodoo/odoo#145980
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit correctly aligns certain header elements when the CTA button
has a larger vertical padding.
Steps to reproduce the issue:
- Install 'eCommerce' on your website.
- In Website edit mode, click on the 'THEME' tab.
- Adjust the vertical padding of buttons to 25px.
- Click on the header in the page.
- In the 'STYLE' tab, select the 'Menu - Sales 1' header.
- Bug: The 'logo" and the 'menu items' are not aligned with the CTA
button.
- In the 'STYLE' tab, select the 'Menu - Sales 2' header.
- Bug: The 'menu items' are not aligned with the CTA button.
- In the 'STYLE' tab, select the 'Menu - Sales 4' header.
- Bug: Bug: The 'cart' button is not aligned with the CTA button.
task-3478334
closesodoo/odoo#145683
X-original-commit: d2f6710bcaa5cee7e77fc4df902929264ffa4830
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Before this commit, the default update_path even if the field was
readonly, it weas returned. So, if you try to create an automated
action on the stock.move.line model and try to add an action, the
button return a traceback because the field is readonly.
After this commit, the method that get the default update_path will
also check if the field is not readonly.
Bugfix Task-Id: 3624328
closesodoo/odoo#146166
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Overflowing search facets do not wrap making them disappear from view
when too long. This can happen when searching a single field for
multiple values (as they are bundled in the same facet).
The problem is fixed by allowing facets to wrap.
Steps to reproduce:
* Open a view with a search (kanban, list, ...)
* Add many, many long terms search for the same field
=> BUG the search overflow outside the search bar
opw-3581553
closesodoo/odoo#146133
X-original-commit: acd476a4ded3ca873e10dc4cc72668efdcb2c629
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
How to reprodruce:
1) Go to product.template view form
2) Open Studio
3) Go to tab 'Purchase' tab
4) Edit list/form view of the seller_ids (supplierinfo)
Before this commit, the domain on product_id of supplierinfo was using
'parent' as if already doing the filter on the view. Because of the complex
domain in the string, a traceback was throw when editing supplierinfo view
with studio on the product.template.
After this commit, the domain on the python side is simpler. The domain for
the view has been moved in the view and changed to not be dependent of the
parent view, but of the context.
Bugfix Task-ID: 3615851
closesodoo/odoo#145586
Signed-off-by: Steve Van Essche <svs@odoo.com>
The aim of this commit is to correct the date of the payment.
Context:
When creating a PoS session and a PoS order on date X
The customer gets its invoice on date Y
the payment date is printed on the invoice
Before this commit:
The payment date will always be the date of the invoice
After this commit:
The payment date will always be the date of the order, the date at which
is was really paid.
Corner case not taken care of in this commit:
Claiming the invoice after the `fiscalyear_lock_date`.
In such a case, the payment date will be set to today (the invoice_date)
again.
This should be really rare as setting that lock date in short time frame
is quite unusual.
closesodoo/odoo#146259
Task-id: 3629054
X-original-commit: 732e43d8a6d4012eafb434952ccb6609f9be8066
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Before this commit, clickall was clicking on an app that redirect to a
tablet mode view. The issue with this is that clickall don't know how to
exit the view, so it was stuck in the view.
This commit adds that view on the blacklist of clickall.
Also, this commit adds an error message when clickall is stuck in a view.
closesodoo/odoo#146216
X-original-commit: 8f365824c9dddacf1b3a40688a30c8498df3d5d4
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when the user tried to quick create a record in
a grouped kanban view (by clicking on the "+" icon of a column, for
instance), and then clicked on the "Edit" button of the quick
create, if the name_create rpc failed, the webclient switched to
the form view and an error was displayed.
The displayed error was about a destroyed component trying to do an
rpc, namely the kanban controller. This is because it does 2 things
when the name_create failed: it opened the form view in a dialog
and it also switched to the form view. The latter was unwanted:
in case of errors, we don't want to switch to the form view but
rather to quick create from a dialog.
The error was actually caused by a small mistake: we use the
record variable to determine if the quick create succeeded and if
we can switch to the quick created record. However, that same
variable was already set before, for another purpose.
OPW 3620671
closesodoo/odoo#146141
X-original-commit: 01bc79051b22f41eff20d860327ed0e41b572cd4
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when browsing the "Events" part of website on Safari
(both macOS and iOS/ipadOS), the page could be loaded only once and
returns a "FetchEvent.respondWith received an error: NotSupportedError:
The operation is not supported." error message on afterward, completely
blocking access to everything under the `/event` path.
This error is actually thrown from the ServiceWorker's `fetch` event's
listener, and more specifically, from the storage availablity check.
Since Safari 17.0, the Storage API - and in this case its `estimate()`
function - has been enabled in WebKit's builds for Apple platforms (see
WebKit PR [1]). But even if this feature should be available in Web
Workers (cf. MDN [2] and the spec [3]), it returns a NotSupportedError
error when called from the ServiceWorker on Safari 17.0+ (but works fine
in the global scope).
This commit works around that issue by wrapping this call in a
try/catch, acting as if not supported when an error happens.
Steps to reproduce (on Safari iOS):
- Install website_event_track module
- Navigate to the `/event` page
- Reload the page
=> Browser level error page "FetchEvent.respondWith received an
error..."
Note: due to the browser's engine restriction on iOS/ipadOS, this issue
also affects all browsers on these platforms.
[1]: https://github.com/WebKit/WebKit/pull/10973
[2]: https://developer.mozilla.org/en-US/docs/Web/API/StorageManager/estimate
[3]: https://storage.spec.whatwg.org/#ref-for-dom-storagemanager-estimate
opw-3553880
opw-3570730
opw-3610167
opw-3629039
opw-3547759
closesodoo/odoo#146190
X-original-commit: 45020635a81ce53ee0769ca54ac733528e4110b1
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Currently, when a peppol document is received, we log a success message regardless of whether the account_move has been created properly or not. This commit changes that to only show the message if everything went well.
A follow up to a fix for opw-3628030
closesodoo/odoo#146236
X-original-commit: d1d35429d6897db7210a98889d6268a4d0d3cbe8
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Commit [1] removed the `email_from` field from the `project.task` model
but forgot to adapt/delete some field occurences.
One of those is related to the form in the website builder which allows
to create task when the form is sent.
Two errors were detected:
- Non critical:
The field is still passed to the form field whitelisting process.
Since the whitelisting is done in raw SQL, it didn't crash or log
anything even if the column did not exist anymore.
- Critical:
The field was still marked as model required in the form JS registry,
altering the form builder behaviors.
One of those is that when the form input related to this field was
re-created (eg when changing / hovering an option in the right panel),
it would lose it's "name" attribute.
Two possible issues from that point:
1. When a visitor submit the form, the "email_from" field value is not
set anymore in the task description and that information is just
lost. You then have no way to reach back to him.
2. (Minor) The auto-fill behavior of the form was not working anymore
Probably more issues were introduced but only those ones got detected as
of today.
Step to reproduce:
- Drop a website form, choose "Create a Task"
- Focus the default "Email" field
- Hover the mouse on the "eye" icon ("Invisible") next to the Position
attribute. If you inspect the DOM, the input has now lost the `name`
attribute.
- If you save, you will face the issues reported above.
- If you then reopen the editor and focus the email field again, the
tooltip will now say that the "null" field is required.
[1]: https://github.com/odoo/odoo/commit/a424cf481c676a230beeb6102fc67bedf472a882
opw-3626573
closesodoo/odoo#146170
X-original-commit: 6679fddbcaf7d9146ab242e0eed61ee0628f047f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Description:
Indexes on a Selection field are never used in a `NOT IN` where clause,
as PostgreSQL doesn't have the complementary values (in DB a Selection
field is just a VarChar) to make use of an index on the field.
The ORM currently doesn't invert
`not in <selection>` -> `in <complement of selection>`.
Benchmark:
Positive impact in the project modules all around, specially for long running
projects where the proportion of "done" tasks are >90% of the
project's task. On a populated project with 10k tasks, 200 of those are
open, there were around 10x improvement on the requests linked to
rendering the kanban view of the project. More elaborate benchmarks are
available in the referenced task.
Reference:
task-3576802
closesodoo/odoo#146168
X-original-commit: 403a7c78f06f6b99233e6fc045bde67f0c670702
Related: odoo/enterprise#52708
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
The view set a domain with `share = False` but the model search for
users with group `group_mrp_user`
closesodoo/odoo#146167
X-original-commit: 25386559629c5e7bbd9decb3fb7ca57ab0ccea18
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Lacking a flush to database before the query used to compute
the gap-in-sequence warning, the gap-in-sequence warning
would stay active even when the all-users lock-date was set.
Which is confusing for the user as they can't do anything about it.
This
- adds the required flushes
- adds a tooltip explaining the warning in more details
as it was deemed confusing
- Adds all the moves that took a sequence number in the query
Task-3613058
closesodoo/odoo#146160
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Julien Alardot (jual) <jual@odoo.com>
This commit fixes a nondeterministic runbot issue during the survey session
management tour suite (that actually contains multiple tours).
It turns out that the first tour is so short that it does not let enough time
to the web framework to correctly initialize everything before it gets killed
(as the tour steps are completed almost instantly).
It's hard to say exactly where the issue comes from, as the error does not
mention anything (we only know that it's a rejected promise):
"""
Error received after termination:
PromiseRejectionEvent(
isTrusted=true,
reason=Event,
type='unhandledrejection',
target=Window,
currentTarget=Window)"
"""
Removing this first tour also removes the nondeterministic issue.
It seems like an acceptable compromise as this tour was not really testing
anything anyway, we now directly start the session from the python code.
(Note: this issue only started occurring in v17).
Task-3637591
closesodoo/odoo#146107
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Current behaviour:
QR code is squished, it's 77x21 px
Expected behaviour:
QR code should be 100x100 px
Steps to reproduce:
1. Go Email Templates
2. Find 'Event: Registration Confirmation'
3. Click on preview
4. QR code is squished
opw-3625701
closesodoo/odoo#145963
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
Current behavior:
When a reward is applied on an order containing different product with
different taxes, the rewarded is divided in multiple lines (one per tax)
This cause issue when calling, the `_updateRewardLines` method.
Because it will consider each line as a full reward, and therefore will
apply the reward multiple times even though the reward is only applied
once.
Steps to reproduce:
- Create a reward with a discount of 5$ in exchange of 100 points
- The reward should give 1 point per 1$ spent
- Create a product with a price of 100$ and a tax of 10%
- Create a product with a price of 100$ and no tax
- Open the POS and add the 2 products to the order
- Select a customer, and click the reward button
- The reward will be applied 2 times (4 reward lines are created)
opw-3583174
closesodoo/odoo#145759
X-original-commit: 8214322a0f06d74005c46d2623972f6eb393cc08
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Steps to Reproduce:
- install service apps and website
- install website related bridge modules
- install quality and related mrp_subcontracting bridge module
- click on website , click on My account
- click on project ,or timesheet,or tasks,or tickets
Issue:
- after clicking,we will notice that breadcrumb indicates 'title' twice
Cause:
- this is because,in mrp_subcontracting , the title for productions is given
without checking the page_name , so that will affect all the titles.
Solution:
- if we gave condition to check the page name for production this issue is
solved.
task-3607053
closesodoo/odoo#144477
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce
==================
- Go to users
- Open the export dialog
- Expand the Groups field
- Add the Groups > Groups/Access Controls field
- Check the import compatibility option
- Expand the Groups field again
=> `TypeError: this.knownFields[id] is undefined`
Solution
========
The expandedFields were not reset. We also need to update the t-key to
take the compatibility state into account.
opw-3378834
closesodoo/odoo#146116
X-original-commit: d2f52abb8ce1b7e5291e0de7d4ea7788f39115bd
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Versions:
---------
- 16.0+
Steps to reproduce:
-------------------
1. In Timesheets, add a new line;
2. link it to a Sale Order project;
3. make it non-billable by clearing the Sale Order Item field;
4. select related project in Project / Configuration / Projects;
5. in Invoicing tab, add yourself and a Sales Order Item, then save;
6. go back to Timesheets;
7. check the Sales Order Item field of the timesheet you created.
Issue:
------
Sales Order Item was changed automatically, this shouldn't happen after
a manual change.
Cause:
------
The `so_line_field` widget used the `this.changeOnEmpty` attribute to
check whether `is_so_line_edited` should be set, but this was removed in
1ecdbfcfbf, hence the field will never be
set when clearing the `so_field` value.
Solution:
---------
On a field change, compare the previous ID of `so_line` with the new ID,
and set `is_so_line_edited` to `true` if they're different.
Related:
--------
odoo/enterprise#52544
opw-3547725
closesodoo/odoo#146062
X-original-commit: bc1ad08286be9bb02d111e49fe095879b649449e
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Levi Siuzdak <sile@odoo.com>
Usecase to reproduce:
- Install purchase and mrp
- On a product set both routes manufacture and buy
- Create a BoM for the product and define a seller
- Sell a unit
- Open the replenishment. Buy or manufacture is set as route
- Go to the settings and set the route not sellected to the smallest
sequence
- Delete the orderpoint and open the replenishment menu again.
Expected behavior:
The new route with smallest sequence is selected
Current behavior:
The same rule is selected and the order used by _get_rule and to
compute the lead time is bypass
It happens because both override of the method are at the same level
(super of stock) and are call arbitrary one before the other.
In order to fix it uses rule_ids that was computed before calling the
function and it contains the real rules used to compute the lead time
closesodoo/odoo#146051
X-original-commit: cad38a349c3486cb199ef8079bdd46cffefd5b2e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Issue:
======
Front camera doesn't open even if we set it in the configuration.
Steps to reproduce the issue:
=============================
- Install attendance
- Go to attendance/ configuration and put front camera in barcode source
- Use mobile : Go to kiosk mode and start scanning
Origin of the issue:
====================
There was a typo in the props values where we assigned `employee` to
`barcodeSource`
opw-3621239
opw-3608019
closesodoo/odoo#145880
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit the clean_assetbundle could unlink invalid
attachment, mostly when generating a no website assetbundle with
a different version than a website one, the website assetbundle will be
deleted.
Generating a new asset bundle attachment /web/assets/439-b4c80c3/1/web.assets_frontend.min.css (id:439)
Generating a new asset bundle attachment /web/assets/440-3723971/web.assets_frontend.min.css (id:440)
Deleting attachments [439] (matching /web/assets/%-%/web.assets_frontend.min.css) because it was replaced with /web/assets/%-3723971/%%%
The issue is that %-%/ will match 439-b4c80c3/1/ and not only
439-b4c80c3/
Note that it looks like this issue existed for a while but was invisible
because before 16.4 clean_attachment was invalidating the ormcache,
hiding the fact that a still valid asset was deleted and regenerated.
The proposed fix replaces the domain with %-_______/. The unique is
always 7 character long. Note that this change was already made in 17.0
when removing the id from the asset url so this doesn't need to be
completely forward-ported.
opw-3558552
closesodoo/odoo#145452
X-original-commit: 2ac466547e01bfd65415a53ae1efc9d45d9299fb
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Revert [1]
Changing `t` into `span` is not allowed in stable, in case some
customization already exist and have xpath that target `t`. The
change OE side [2] is problematic too: if a DB has the old XML version
(`t`) and the user tries to install `industry_fsm`, an error will be
raised:
`Element '<xpath expr="//span[@t-if='record.partner_id.value']">'`
`cannot be located in parent view`
[1] b3e3c92b52
[2] odoo/enterprise@094009669b
OPW-3629163
sentry-4700256130
closesodoo/odoo#146094
Related: odoo/enterprise#52682
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Issue Description:
==================
Issue: Inability to validate transfers generated from the POS's "ship later" feature.
Steps to Reproduce:
===================
1. Create a new user or configure Marc Demo to have only User access in Sales, Inventory, and POS.
2. Create a storable product that can be sold in POS, where the product category uses automatic FIFO valuation.
3. In the POS configuration, enable the "Ship Later" feature.
4. Log in as the new user (e.g., Marc Demo).
5. Sell the new product in POS, choose "ship later," and confirm the order.
6. Go to Inventory and locate the created transfer (reference Shop/000X). You may need to disable all filters to find it.
7. Attempt to validate the transfer and encounter an access error because the User is not an Accounting or Purchase user.
Proposed Solution:
==================
The solution involves adding sudo privileges to the creation of account moves in the POS. This will allow the validation of transfers generated by the "ship later" feature, even for users who are not designated as Accounting or Purchase users. By implementing sudo, we can ensure that the inventory valuation and account moves are correctly processed, resolving the access issue that arises during transfer validation in the POS system.
opw-3572111
closesodoo/odoo#146059
X-original-commit: cf08cbfe46908380da510bf9e3994b34da798d76
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Ilya Rudy (ilru) <ilru@odoo.com>
To reproduce:
- Create and confirm MO with a tracked component (qty 1, in stock)
- Open the shop floor app and click on the move line for the component
- In the pop-up, change the quantity to 2 and click save
Current behavior:
Crash on an infinite recursion.
The issue was introduced in [1], as setting picked to True in the
stock.move write triggers another call to write on the stock.move,
resulting in the infinite recursion.
Expected behavior when this PR is merged:
The quantity on the stock.move is updated, and the popup closes.
By just updating the vals of the write, we do not trigger the write
method again and avoid the recursion while still maintaining the wanted
functionality from [1].
[1] https://github.com/odoo/odoo/commit/fe508c6b2cb1b92d7b063cc194a3dad37f4eb255closesodoo/odoo#145922
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Steps to reproduce:
- Install l10n_fr
- Switch to a French Company (i.e. FR Company)
- Create an invoice for a contact from Monaco with a VAT number
=> The default fiscal position is "Import/Export Hors Europe + DOM-TOM".
In France, for Monaco, it should be "Domestique - France".
Solution:
Create a country group with France and Monaco and set it to
"Domestique - France" fiscal position.
opw-3617761
closesodoo/odoo#146058
X-original-commit: 2515cdc65f30e29029bafeefed2c6c4b7a2b1ac1
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Summary
-------
Foreign companies that trade with non-enterprises in the EU may have a
VATIN starting with "EU" instead of a country code. However, the tax ID
validation does not account for that.
Steps to reproduce
------------------
* install base_vat and contacts
* create a Canadian company with a tax with the format EU00000000
=> you should be met with a validation error.
opw-3551347
closesodoo/odoo#146049
X-original-commit: 6e11c34c660cecea7e8a0b56f7f8f3baba70b0c9
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Fix a typo in an account name.
closesodoo/odoo#146035
X-original-commit: 543dea1c2516aef4faa0e32947ca7c75ff48f212
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
Issue:
======
Marking an activity of calender event as marked with text raises an
error.
Steps to reproduce the issue:
=============================
-Go to any contact and create a meeting with him as an activity in the
chatter.
- Mark the actvity as done and add some text as feedback.
- An error showing that the record is deleted.
The issue already solved here , this commits only add the test.
opw-3623719
closesodoo/odoo#146045
X-original-commit: 787f2f44961b9b5283b7bdc944acc2e8284212cc
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Speedup computation of tax_country_id by first filtering
on record with fiscal_position_id.foreign_vat. Then group records
without foreign_vat by company_id and call __setitem__ on each group.
In the best case (1 company and no record with foreign_vat) this gives
a speedup of 7.37s -> 450ms for 1000 records.
This also speeds up the importing of account_bank_statements.
opw-3576526
closesodoo/odoo#146032
X-original-commit: 9501cd4b5cd888c2aa16735f77d12d92618ea5fc
Signed-off-by: Aurélien van Delft (avd) <avd@odoo.com>
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Description of the issue/feature this PR addresses:
When installing the Singaporean loca, the Tax ID label is renamed to
"GST No.". This is global change meaning the label is changed for Singaporean
companies but also for any other company. This should not happen as the rename
should only be applied when using a Singaporean company and viewing any
company.
For example :
- Belgian company viewing Belgian company : GST No.
- Belgian company viewing Singaporean company : GST No.
- Singaporean company viewing Belgian company : GST No.
- Singaporean company viewing Singaporean company : GST No.
Desired behavior after the PR is merged:
This commit changes the way the Tax ID label is changed. The label is not
changed upon intallation of the Singaporean loca but is actually adapted on
each opening of a company view so that the tax id label of the company
being USED is applied instead of the default one.
For example :
- Belgian company viewing Belgian company : Tax ID
- Belgian company viewing Singaporean company : Tax ID
- Singaporean company viewing Belgian company : GST No.
- Singaporean company viewing Singaporean company : GST No.
task-3530802
closesodoo/odoo#146020
X-original-commit: e4594310d3dd06b2e2bc047317c90bffe30a57f0
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Thomas Becquevort (thbe) <thbe@odoo.com>
An empty header was left in invoicing config settings after the refactoring of res_config_settings.
This commit removes the empty header that creates empty space in Customer Invoices section of the settings.
task-3619987
closesodoo/odoo#145989
X-original-commit: 1605c3287163dc35093a0e3e82e63407fcbedfa3
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Steps:
- Create a sale order
- Send it to the customer
- Go to the link in the mail
Issue:
The avatar of the sender is not displayed in the portal chatter but should be.
Reason:
Since 16.0 some rules have been added on ``sale.order`` Model, so you need to log in to get the read right
Solution:
After discussing with reth, we can create a new route in ``portal`` controller just for avatar to be showed
by bypassing record access rules but ensure token used is valid.
opw-3383983
closesodoo/odoo#145931
X-original-commit: 1e2811139215ad29d7e25641a541c3f4c152649e
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Eteil Junior Djoumatchoua (etdj) <etdj@odoo.com>
In a Safari or with GNOME web browser:
- Run a Odoo server without the password policy app
- Go to Settings->User->Select an user
- Click on the action menu and "Change Password"
Current Behaviour
-----------------
The "New password" column have a width of 0.
Expected Behaviour
------------------
The "New password" column is shown.
This commit sets a min width to the new password column to avoid this
weird shenanigan from Safari of setting the width to 0. After some
reverse engineering of understanding why Safari does that I was not able
to find why.
closesodoo/odoo#145930
Task-id: 3573558
X-original-commit: 0dbb0938a90ee0155684bd5bdc7f50f0a9434b9d
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Signed-off-by: Florent Dardenne (dafl) <dafl@odoo.com>
Before this commit, the equality check performed by the datetime service
relied on a JSON-strigified version of the value on one end, and on an
array of ISO strings on the other end. This meant that the value was
never equal to itself and that the `onApply` callback would be called
even if the value remained unchanged.
This commit fixes that by ensuring that the compared values have the
same shape.
closesodoo/odoo#145929
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
In the commit 7675905 a t-for loop was introduced in the `ActionpadWidget`
override from `pos_restaurant` where the t-key value was undefined.
This commit fixes the issue by giving a proper value to the t-key.
closesodoo/odoo#145919
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Issue:
======
When we have a product with `out of stock:continue selling` disabled,
accessing the shop page will give an access error.
Steps to reproduce the issue:
=============================
- Make sure to have a storable product with `out of stock: continue
selling` disabled in the sales tab of the product.
- Log out and go to shop
- Access error related to warehouse records
Origin of the issue:
====================
The function `_website_show_quick_add` being called from the template in
odoo/addons/website_sale/views/templates.xml to display the shopping
card button in at the bottom of the product. Since the user is public he
doesn't have the right to access the record in warehouse to see if the
product is out of stock or not.
The test `test_back_in_stock_notification_product` already tests the fix
and doesn't work without this fix , so no need to add extra test.
opw-3620172
closesodoo/odoo#145916
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
