The `fetchmail` module is build on top of the `mail` module and enables
the incoming email capabilities. However, using the `mail` without
incoming email server is not a good use case.
This commit merges the `fetchmail` moudule into `mail` and lessens the module
complexity, along with adapting the xml/external ids in the dependent modules.
task-2797458
closesodoo/odoo#94143
Related: odoo/upgrade#3615
Related: odoo/enterprise#28659
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In this task, we modified the template layout to match the other
mail notification template and make it compatible with Outlook.
closesodoo/odoo#92847
Taskid: 2791286
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The option to be notified when an item in your wishlist is back in stock
only shows when the debug mode is enabled
Steps to reproduce:
1. Install Inventory and eCommerce
2. Go to Settings > Website > Products and enable Wishlists
3. Open Website and go to the website
4. Open the shop and add 'Three-Seat Sofa' to your wishlist (with the
heart button)
5. Open your wishlist, the product is out of stock but you can't see the
'Be notified when back in stock' button (it's only visible in debug
mode)
Solution:
Change the groups for which the button is displayed
Problem:
The button was restricted to `base.group_no_one` which refers to debug
mode
opw-2904847
closesodoo/odoo#96353
X-original-commit: 50366db4a51bf3191f5e37420ff2499c3d5820bc
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
The codeview of mass_mailing had the wrong height in non full-width
contexts.
task-2894177
closesodoo/odoo#96342
X-original-commit: ee001e843a0a02f04030f0959c7db58beaaa3a3b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
To reproduce
============
- Make sure you have a product with variants with grid entry enabled.
- Make sure there is "value price extra" on some of the attribute values of the product.
- Make sure multicurrency is enabled and there is a pricelist using other than the main currency of the system, to compute the final price from product sales price.
- Then try to create a new sales order, using that pricelist, adding the product to it.
A traceback is raised.
Purpose
=======
the method `_convert` expects the `company` argument to be a `res.company` and not an `int`
Specification
=============
to solve the issue we use `company` instead of `company.id`
opw-2897688
closesodoo/odoo#96333
X-original-commit: aa5076941c48b660007be0bda3eb73e965bea931
Signed-off-by: abla001 <abla@odoo.com>
Steps to reproduce:
- Take a product sold on the e-commerce and add taxes
- In the Website settings chose the product prices to be
shown tax-included
- Add the snippet "Products"
Problem:
The price shown on the snippet is tax-excluded while the
price shown on the product page is tax-included. The
price on the snippet should also be tax-included.
Explanation
Bug introduced by commit 9e99a9df46
using the _get_contextual_price ignored the option where the taxes
needed to be computed. To solve the issue we create a new function
that calls _get_contextual_price but also add the taxes if
necessary.
opw-2894461
closesodoo/odoo#96285
X-original-commit: a029aea6e332eca8abbc0591f8885afaaa223e75
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Margin top of `we-selection-items` was removed during the migration of
BS5 to avoid warning on runbot, but we have to restore it for non BS
`dropdown-menu`.
Ref:
odoo/odoo@e1ea58c941closesodoo/odoo#96186
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
NOTE that this is also a refactor.
When an order has a fiscal position, deleting it from the ui is impossible
unless it's deleted from the localStorage. To reproduce:
- Make an order with fiscal position
- Validate the order, and in receipt screen, click next order.
- This will remove the paid order from `pos`.
- [BUG] Refresh the page the product screen will focus on that order.
- This is because the order is kept in the localStorage.
Why? `save_to_db` is dependent on `pos.selectedOrder` when there is a fiscal
position in the order.
How come? This is because when computing tax mapping, it's using the
`selectedOrder`. And `save_to_db` is triggered because when deleting an order
`selectedOrder` is set to a order.
The proposed change removes this dependency of an order to the
`pos.selectedOrder` and it fixes the issue.
closesodoo/odoo#96090
Related: odoo/enterprise#29525
Signed-off-by: Masereel Pierre <pim@odoo.com>
Since the migration to Bootstrap 5, we can now use BS 5 utility classes
in the discuss_public view.
This commit simplifies the scss related to discuss_public.
task-2909016
closesodoo/odoo#95772
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, it was impossible to migrate from one payment
acquirer to another as the only way to do so was to change a payment
acquirer’s state to ‘disabled’, subsequently disabling all tokens of that
acquirer (detrimental for eg. running subscriptions).
After this commit, payment acquirers have an additional boolean
‘Published’. With this functionality, users can safely migrate by
keeping an acquirer ‘enabled’, but invisible for customers.
There are five combined states an acquirer can take:
‘enabled’ & ‘published’: Visible to all users
‘enabled’ & ‘unpublished’: Visible only to internal users
‘disabled’ & ‘unpublished’: Same as previously ‘disabled’
‘test’ & ‘published’: Same as previously ‘test’
‘test’ & ‘unpublished’: visible only to internal users
task-2871459
closesodoo/odoo#94242
Related: odoo/upgrade#3688
Related: odoo/documentation#2308
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
When a customers paid a transaction through the `/payment/pay` route and
the transaction was authorized, the message for confirmed transactions
would be shown on the `/payment/confirmation` route instead of the one
specific to authorized transactions.
task-2527323
closesodoo/odoo#78843
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
When a customer paid for an invoice linked to an SO and the transaction
was authorized, the badge 'Waiting Payment' would still be shown on the
list of linked invoices in the portal view of the SO. Since authorized
transactions are considered as confirmed payments, the 'Authorized'
badge is now shown instead.
task-2527323
Part-of: odoo/odoo#78843
The product configurator doesn't allow you to use non-integer quantities
Steps to reproduce:
1. Install Sales
2. Go to Settings > Sales > Product Catalog and enable Product
Configurator
3. Create a Quotation and add product 'Conference Chair (CONFIG)'
4. In the product configurator, specify 3.5 as quantity and click on
'ADD'
5. The total price is wrong
6. Add the optional product 'Chair floor protection' and confirm
7. The quantity of 'Chair floor protection' rounds to 3
Solution:
Parse the quantity as a float instead of an integer (and replace
potential commas to dots in case of different decimal separator), get
the quantity from default_quantity for the rpc call (as it was converted
to an integer because of its type) and convert the quantity to float in
the controllers
Problem:
parseInt was used to retrieve the quantity and the controllers converted
the quantity to an integer. The field quantity of the
SaleProductConfigurator is of type Integer, which rounded the quantity
when opening the configurator.
opw-2896367
closesodoo/odoo#96275
X-original-commit: 884a99357c1c44b2201e7116d7f6189626695f92
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Have an editable list, select a record, click either on a group header or on the list header
press the arrow down key.
Before this commit, there was a crash because we attempted at navigating with the keyboard inside the list from
a wrong entry point. The crash occured because no record was selected.
After this commit, when clicking on something else than a data row or a column that is sortable
we unselect the record. Hence there is no crash when navigating with the keyboard
closesodoo/odoo#96233
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Currently, if you try to create an opportunity through the smart button on a contact form, a lead is created.
A lead created from a customer should be an opportunity.
opw-2886623
closesodoo/odoo#96268
X-original-commit: 415c8393f25ab47da45d15ebc455660bfa440389
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In this merge we introduce a new module ``test_mail_sms`` that holds the
tests for sms application, like ``test_mail`` does for mail. Currently all
sms tests are inside ``test_mail_full``. After this merge code is moved
from ``test_mail_full`` into that module. Full testing module should be used
mainly to test integrations with a lot of submodules and for performance
tests, not testing details of SMS implementation.
We also add ``mass_mailing_sms`` as dependency of ``test_mass_mailing`` so
that both mailing types are tested in the same module. It eases maintenance
and writing of tests. Mass mailing SMS tests from `test_mail_full`` are
therefore moved in ``test_mass_mailing``.
This merge also allows some cleaning in classes used in tests, to have
classes in ``test_mail_sms`` and ``test_mail_full`` that contain everything
necessary to test mail features.
This merge also adds some additional features
* new mail related tests;
* new performance tests;
* some cleanup in tools;
* fixup in a randomly crashing test;
* updater query counters;
See sub commits for more details.
Task-2890111 (Test Mail/Mass Mailing: SMS tests reorganization and move)
closesodoo/odoo#96223
Related: odoo/enterprise#29601
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to add tests on ``failure_reason`` usage of
notification model. Tests already exists for MailMail and other fields
but not that specific one. Followup of odoo/odoo@d895f3514e
New tests are added to check the usage of email_to and email_cc when
sending emails. Notably wrong usage of email_cc (lost formatting, copy
of all sent emails) is asserted to be fixed afterwards.
A performance test about batch sending is also added.
Prepares Task-2684479 (Mail: Better send error storage and display)
Part-of: odoo/odoo#96223
Purpose is to ease addition of new tests related to email sending, notably
to check failure reasons.
Prepares Task-2684479 (Mail: Better send error storage and display)
Part-of: odoo/odoo#96223
In this commit we introduce a new module ``test_mail_sms`` that holds the
tests for sms application, like ``test_mail`` does for mail. Currently all
sms tests are inside ``test_mail_full``. After this commit code is moved
from ``test_mail_full`` into that module. Full testing module should be used
mainly to test integrations with a lot of submodules and for performance
tests, not testing details of SMS implementation.
We also add ``mass_mailing_sms`` as dependency of ``test_mass_mailing`` so
that both mailing types are tested in the same module. It eases maintenance
and writing of tests. Mass mailing SMS tests from `test_mail_full`` are
therefore moved in ``test_mass_mailing``.
This commit also allows some cleaning in classes used in tests, to have
classes in ``test_mail_sms`` and ``test_mail_full`` that contain everything
necessary to test mail features.
Task-2890111 (Test Mail/Mass Mailing: SMS tests reorganization and move)
Part-of: odoo/odoo#96223
Previously, the useService hook would call _protectMethod, which wraps
async methods so that any call to them after the component has been
destroyed throws an error, and any call that was started while the
component was alive but returned after the component was destroyed would
return a pending promise such that no more component code is executed.
In doing so, it would for some reason bind all the methods to the
service, this prevents some functionalities where a method would return
a differently configured version of that same service, on which you can
call the methods again (eg: orm.silent), as the modified service's
methods would not be bound to that modified service.
This commit fixes this issue by not binding the methods eagerly, and
introduces a test for all these behaviours.
closesodoo/odoo#96121
X-original-commit: 518a93a5487f62bd9b460412d4775cd0ac80a262
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Port of legacy's BasicRenderer for WOWL views.
In a nutshell: Tooltips are problematic in touch devices as they are
meant to appear on hover... which doesn't happen with touch events.
This commit implements a "tap-to-show" behavior which let the user see
the Tooltip by pressing the element, and letting it disappear when the
pressure ends.
Also, make the touch detection easier to test/mock.
closesodoo/odoo#95924
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Port of legacy's BasicRenderer for WOWL views.
In a nutshell: Tooltips are problematic in touch devices as they are
meant to appear on hover... which doesn't happen with touch events.
This commit implements a "tap-to-show" behavior which let the user see
the Tooltip by pressing the element, and letting it disappear when the
pressure ends.
Part-of: odoo/odoo#95924
Before this commit Chrome's "touch mode" was enabled in both desktop and
mobile-like tests suite (when run headless).
To better match real usecases, this commit adds an option to
enable "touch mode" only in mobile tests suites; keeping it disabled in
desktop ones.
Part-of: odoo/odoo#95924
- use 'browser' as abstraction, allowing to mock touch detection in
QUnit tests
- remove deprecated IE 10 touch detection (using non-standard
MSGestureChange event)
- some linting
Note: touch detection using "ontouchstart" is a quite common practice.
It's useful to note that, when in touch mode, browser's have different
values for it ("null" in Chrome, "Function" in Firefox...) but all
agrees to have "window.ontouchstart" being "undefined" when in non-touch
mode.
Part-of: odoo/odoo#95924
The legacy ProgressBar could receive a title in props that it had to
display.
In this commit, we add support for the title props in the new
ProgressBard field.
closesodoo/odoo#95922
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The previous commit removes a good part of the barcode form view. The
rest of the code was only used by the barcode_handler widget. Since it
is now much simpler, we can just implement the behaviour: simply set the
value to the barcode, so onchanges can be properly called.
closesodoo/odoo#95892
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
With this commit, we simplify the way barcodes prefixed by `O-CMD.` are
handled, by simply executing a ui action whenever it happens. The code
is much simpler, instead of having to add a widget=barcode_handler in a
specific view.
Note that it changes the behaviour: now, barcodes are available
everywhere, instead of just a selection of form views. This seems more
natural, since we consider that the barcode scanner is basically some
kind of input device.
Part-of: odoo/odoo#95892
Doing a `search_count` on millions of records could be very slow. On
large databases, the pager counter "1-80 / 8000000" could take several
seconds just to get the total number of records.
This commit limits the counter in list and kanban views to 10k records,
and shows "1-80 / 10000+" if the limit is reached. If you click on
10000+, it updates with the real count (or if you go up to 10000 with
pager or input value).
The search_count on res.partner of odoo.com takes 4s. With this patch,
it will take ~20ms.
Task 2761165
closesodoo/odoo#95642
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Damien Bouvy <dbo@odoo.com>
The new implementation of float field has some problems dealing with
external changes that would impact it. The specs are changed to format
on blur. It was overly complicated not to as the behavior of all input
fields are controlled through the input field hook.
Note: in the past, formatting would only occur after a save action, now
the formatting is on blur.
The input field hook had some issues dealing with invalid and dirty data
so this has been fixed as well.
closesodoo/odoo#95364
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When unselecting an export template, the list was empty
instead of just keeping the current list. I also added
some tests for this component introduced in Owl recently.
Some scss changes have been done to remove unnecessary
lines from the file and fix the style in a small window.
With a small window, items from the export list are not
draggable and the list must be placed at the bottom
part of the dialog
closesodoo/odoo#95226
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
For modules that fully implement Stripe Connect, i.e. that sign requests
with their own API keys, there was no way to pass contextual data to the
proxy when making those requests.
This commit addresses the issue by populating the `proxy_data` param
present in all proxy's routes' signatures with an extendable `dict`.
task-2917229
closesodoo/odoo#96279
X-original-commit: 5df308c58e02c9ca3287c124c0df4e359817ce16
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
After the following steps, snippets overlays are not properly removed
from the DOM:
- In edit mode, drop 2-3 snippets in the page.
- Click on these snippets to activate their overlays.
- Drag and drop a popup in the page.
- Drag and drop a snippet in the popup.
- Move this snippet inside the popup thanks to the move handle button.
- Click on the "eye" button to hide the popup.
- Click on snippets of the page, the overlays are no longer removed when
they should.
It was because since commit [1], it is allowed to define an element
in which '_destroyEditors' destroys the editors but we forgot not to
completely empty the array that contains them.
But anyway, the editors list does not need to be updated in
'_destroyEditors' since commit [2] as it is already done in the
'destroy' method of 'SnippetEditor'.
[1]: https://github.com/odoo/odoo/commit/b7d522e9e7e31ac6bf926aae65e58d9f6cfa8903
[2]: https://github.com/odoo/odoo/commit/2a19a83762c1bc74dd7336378d254ab6da8e3a22
task-2799602
closesodoo/odoo#96267
X-original-commit: 0e97847cf42db935522f5f834f6fcb86de02eae3
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When both a specific inheriting view and a non-specific base view are
written simultaneously, the specific inheriting base view must be
updated even though its id will change during the COW of the base view.
This commit sorts the list of written views in order to first handle the
website-specific ones then the base ones which might change some of the
ids of the already updated view.
Steps to reproduce in 14.0+ (no scenario found in 13.0):
- Create a new website.
- Configure the language selector layout to "Inline".
- Configure the language selector layout to "None".
=> Error notification was displayed and change was not applied.
task-2885882
closesodoo/odoo#96248
X-original-commit: 317eea48186c948009399daedf70dd407f6a9ca8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Small oversight of: 4c6a010730
This commit simply hides the stat-buttons when the mail.activity is opened in
the popup form.
When in that popup form, you don't want to switch your context, especially
considering the only button currently available allows you to open the related
document (from which you just opened the activity popup form, creating a loop).
Task-2920490
closesodoo/odoo#96238
X-original-commit: 7b6e700d7e7c54cac0200e98b4eb04af9f115608
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, in large database the time to unlink is very long.
Before 500 ms after a few ms
closesodoo/odoo#96236
X-original-commit: c17e0a6702e58ba784c70bdb04f6a455e6d5b727
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Reproduction:
1. Install Attendance app
2. Create a new internal user “kiosk”, with only access right “Kiosk
Attendance” for app “Employee”, other places as blank
3. Make sure the Settings for Attendance app, Employee PIN is unchecked
4. In an incognito tab, log in as kiosk, go to Attendance, click “kiosk
mode”, then “identify manually”
5. Choose an employee, with a warning message “Wrong pin”
Reason: A recent update refined the user group check for the
attendance_manual function. Checking if the user is an officer in the
Attendance app can be over strict. However, after discussing with yti,
we decided to pop up a warning message for security reasons when the
user would like to use Kiosk mode without pin code.
Fix: Add a warning message for higher access right requirement
opw-2898452
Related fix in V15: https://github.com/odoo-dev/odoo/commit/2975c0539d8c2781ff56a9f8be8e302d45b7d80bclosesodoo/odoo#96230
X-original-commit: 82f2966ed5b3afd30ac5b18c32af7993746fc681
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce:
- Install Time off and timesheet modules
- Create a public holiday with no "working hours"
- Then edit it and add it with working hours used by some employees
Expected behavior:
Adding the working hours makes that the global time off meets the
requirements to create timesheets. Then the employee related to the
new "working hours" is going to have timesheets created for this
holiday.
Current behavior:
No timesheet is created.
Explanation:
The write function of the global time off only updated timesheets
when the dates where modified. We add the update in the calendar_id
modification case and with it the new conditions to create the
timesheets. (working hours = calendar_id)
opw-2879882
closesodoo/odoo#96226
X-original-commit: a255a743b5296570aab166a5e275a323a1792b60
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
When a timezone before UTC is selected (e.g.: US/Pacific), the highlighted days
of some events are not rendered on the correct day (offseted one day before).
More technically, events wrongly displayed will be the ones where:
event.start_date.hour < (UTC - current_tz)
Step to reproduce the issue:
1. Change the Odoo user and your computer timezone to any timezone matching the
condition above (e.g.: US/Pacific)
2. Create an event matching the condition above (e.g.: a full day event is
the easiest)
You will see that the day that is highlited is the day before the real date
of the event (e.g.: 14th July is highlited while the event is a whole day
event the 15th of July)
Solution: The issue is that the cursor (highlight of the day), doesn't take
into account the timezone of the calendar (which is the timezone of the
computer). Consequently, the highlight is sometimes done on the wrong day.
As stated in commit [1], the `FullCalendar` library contains a `start` and
`end` property that takes into account the timezone of the calendar (as
described in [2]).
[1]: https://github.com/odoo/odoo/commit/94018575c6ac21fc94591c3265e017c769d87c0c
[2]: https://fullcalendar.io/docs/event-object
opw-2830697
closesodoo/odoo#96224
X-original-commit: 8764fdccb395875de5682f9019e0e99fde59f286
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
Before this commit, if you are on the time off dashboard calendar of a company
that is not set as your user's default company, no time off is displayed.
Also, if you try to consult your time offs on the dashboard tree view and if
you have one leave with a leave_type without company on a company that is not
the one you're logged in, you'll get a access error.
This commit fixes both issues.
taskID 2893659
closesodoo/odoo#96199
X-original-commit: 6e604bd8bb1d6011482a9ce1778a71a108d0c610
Signed-off-by: Kevin Baptiste <kba@odoo.com>
With Calendar and CRM installed:
- Create a lead and a meeting related to that lead.
- Delete the lead.
- Go to the meeting form view from the calendar App.
- Click the Document action button and nothing will take place.
After this commit if you delete the lead, you will no longer be able to the
see the button as document information is correctly reset.
Task-2917174
Closesodoo/odoo#42450Closesodoo/odoo#47497closesodoo/odoo#96190
X-original-commit: 71ccb7dae43a13521f2a290ce76cafd8fb5b963f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The error message should not be copied for obvious reasons. A new request
should not begin in error state.
CLosesodoo/odoo#43603
X-original-commit: 613dba74b66c51d358e7a6590b6cbfdef81a62b8
Part-of: odoo/odoo#96190
MAHAMADASIF ANSARI