Steps to reproduce:
- install "sale_management" module;
- create a quotation;
- add a product;
- click on "Search More...";
- create a favorite filter;
- leave and return to the Dialog window.
Issue:
No previously saved filter appears.
Cause:
The `loadIrFilters` parameter has a default value equal to `false`.
Solution:
Set the value of the `loadIrFilters` parameter to `true`.
opw-3105096
closesodoo/odoo#108946
X-original-commit: 7b60ee37e31d92d79108bd4e472553a452c2b0be
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
# Steps to reproduce
* install eCommerce and Sales
* go to settings and activate `Discounts`, `Pricelists` and
set `Display Product Prices` to `Tax Included`.
* create a pricelist with a discount, making sure to set (in the
configuration tab):
* `Discount Policy` to `Show public price & discount to the customer`
* `Selectable` to `true`
* go to a product's page, select the pricelist you made and add the product
to the cart.
* go to the shopping cart
# The Issue
On the shopping cart page, the pre-discount price should be tax-included
,but it is not.
opw-3112462
closesodoo/odoo#108935
X-original-commit: f4095614e8a875d66efbbb8c579c73c52b8a1c1c
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
In the website edition mode, the pricefilter option was displayed even if the attributes were not (top and left). The pricefilter was also depended on the fact that the user was displaying categories or not. After improvement, the pricefilter only depends on the attributes display (top or/and left).
Also, if the attributes are activated and only displayed on the top part of the website, then the pricefilter (if activated) should also be displayed only on the top part, and not on the left anymore.
task-3092992
closesodoo/odoo#108934
X-original-commit: b4c3548736f6c19d10a3fc4f358e7303f02d8a81
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
When a record gets deleted, there is no more collaborationResId.
If there is no collaborationResId, prevent the collaboration to
restart, otherwise it will try to subscribe to a channel.
When trying to connect to a channel without record, there
is a cache miss being logged.
Task-3045910
closesodoo/odoo#108933
X-original-commit: e15e8fa1b039cb200686cf49f49075ec7d5486d4
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
In order to display all the category of the filmstrip, It was possible to use either the small bar by clicking on it and dragging, or to use the sliding move on the track pad. Since the bar to be dragged is very small, it was difficult to use it. Being able to click and drag everywhere on the filmstrip makes the move easier for the user.
task-3056398
closesodoo/odoo#106795
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
If we use the token to connect a IoT in Windows
We execute the file rename_iot.sh
So with this commit we give the ability to rename
the IoT only in Linux (with a raspberry)
closesodoo/odoo#108922
X-original-commit: a2bf3c7576f63eb037440c7bf076f5c0b50109d8
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
before this commit, there is no form view defined for the ir.actions.client model, so opening the form view of this model returns the odoo auto created form view, which is not looking good in ui.
the form can be opened by clicking on Edit Action button in the debug tool from a client action menu like Discuss
closesodoo/odoo#108829
Signed-off-by: Julien Castiaux <juc@odoo.com>
Unable to print the customer address on invoice report while the company country is INDIA and bill to ship to address is different.
To reproduce the issue:
Step 1: Create an Indian company
Step 2: Activate Customer Addresses from setting
Step 3: Create an invoice with a different Bill to Ship to address
Step 4: Print the invoice
boom! The customer's address is not there!!
Origin from: https://github.com/odoo/odoo/commit/eb23c0c9d513bdefba20f523e70a807f9a634c57closesodoo/odoo#108908
X-original-commit: 2a83bb3079462bda720935f05dd46241ccae5996
Signed-off-by: Laurent Smet <las@odoo.com>
Steps to reproduce
==================
- Use a mobile viewport
- Go to Expenses
- Create a record
- Enter a description and a category
- Click on Action
- Click on Attach Receipt
-> Nothing happens
Cause of the issue
==================
When the button is clicked, the dropdown is closed. This means that the
AttachDocumentWidget and FileInput Components are both destroyed.
Solution
========
Instead of using the FileInput Component, use an input element outside
the DOM.
We also use `this.env.services.orm` instead of `useService("orm")`
because the last one does nothing when the widget is destroyed
opw-3065590
closesodoo/odoo#108897
X-original-commit: 84d50b40f150f251a81e128fa9645d7fcc729dab
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Drop zones are available outside form when dragging form fields.
This leads to errors whenever the field is dropped outside a form.
This commit removes all drop zones outside the form when a field is
dragged.
Steps to reproduce:
- Edit Contact Us form.
- Drag'n'drop a field to the footer.
=> Error popup (should not be allowed in the first place)
task-2855670
closesodoo/odoo#108863
X-original-commit: 31aec4f89eea5f6095e420137c9603732674901c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Before this commit, domain selector did not support
selection field with "in/not in" operator because the
field does not accept these operators.
This commit adds the support as the operators can still be used.
closesodoo/odoo#108628
X-original-commit: 8ddd5e60f34f2ae9ca52fe936dc8da7054d1dc5e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the domain selector did not list the
operator if it is not accepted by the field
i.e. [['state', 'in', ['draft']]] is not listed in the domain
selector because "in" is not accepted by a selection field.
Now, the domain selector shows the operator even if it
is not accepted by the field.
X-original-commit: 2ae3adbce8cae17116f96f0a86296e41faf55246
Part-of: odoo/odoo#108628
before this commit,
in the translation dialog for a model_terms translated field, English term and
translated terms are shown in different rows
after this commit,
An English term and its translated term are in the same row.
opw-3086352
closesodoo/odoo#108900
X-original-commit: 6cfede8c9b7ac317a602d36a227d7809c3b21964
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
before this commit, on clicking the dashboard from community edition the message is shown that "No default view of type 'gantt' could be found !". similarly for cohort and map views also.
as gantt,map and cohort view is part of enterprise edition, removing it from actions.
closesodoo/odoo#108899
X-original-commit: 6729613b5aef8eaaa62b5f76165fafbb46b94be5
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Steps to reproduce
==================
- Go to Expense
- Type some random string in the search bar in order to have no match
- Click on one off the app button
-> An error occurs
Cause of the issue
==================
The QRModal was not ported to owl
opw-3070434
closesodoo/odoo#108898
X-original-commit: d3b3e6ebb228453938aeac8286f7e3a916b6a027
Signed-off-by: Kevin Baptiste <kba@odoo.com>
utilize the full width and fix the typo
closesodoo/odoo#108896
X-original-commit: f5d700f33a97014c79f93a9415ce51bf7c77d6be
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
* = event, event_booth, website_event_questions
We used to provide data for the event templates (event.type) to provide a basic
configuration to play with. However, they are not much helpful, and sometimes
can confuse the users.
This commit removes the data records for the event templates, and on the
m2o field on event, now we let users create/edit them on the fly so that
they can explore the feature by themselves.
We have also added demo data to the 'Exhibition' and 'Sport' templates,
having booths and questions, respectively. Along with that, we have added
relevant data to the demo events where both templates were used; and set
auto-confirm to be false by default when creating a new event template.
taskID-2854123
closesodoo/odoo#99421
Related: odoo/upgrade#3849
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, processing of pinned channels during
init_messaging was slow due to sorting them in sidebar
of discuss.
This commit improves the sort so that we do a binary insertion
on add rather than push + quick-sort.
Before what took 2.2 seconds now takes around 0.6 seconds.
closesodoo/odoo#108839
X-original-commit: dd4c3c0a8e38147065980cf2c431b056a5253255
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Some basic fields were missing in the front-end product creation modal (i.e. the sales price).
task-3093208
closesodoo/odoo#107420
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Compare list price as base price or list price in comparison or comparison preview
task-2795129
closesodoo/odoo#87134
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
From _snailmail_create function the value passed to error_code selection field
is ATTACHMENT_ERROR. However it is not existing the selection field.
In this commit we add the missing value to selection field.
closesodoo/odoo#108226
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Some buttons/actions were unsuitable for icons (were made for images).
fa-icon for toggle icon spin was misleading ("refresh").
task#2737569
closesodoo/odoo#104163
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
See previous commit, it fixes duplicate URLs from sitemap.
It appears when there is a custom defined sitemap method on a route
defined with multiple endpoints.
There will be as many duplicates as there is endpoint.
closesodoo/odoo#108670
X-original-commit: 9ca24c3020d98dcd6e9266ae76adb13afbf1bd40
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Before this commit, we have redundant loc in sitemap.
When we iter the rules from the routing map, the comparison between
two same endpoints are not equal since httpocalypse.
After this commit we compare the function of the endpoint to know if we
have already processed it or not.
X-original-commit: c408de398c6b4e59cd9a233df251147d8750b9f2
Part-of: odoo/odoo#108670
Before this commit:
While creating a website: in the footer, when trying to edit the link mailto:
there is an "https://" added and preventing the link to work successfully.
After this commit:
- Whenever we try to edit mailto link and save it then in _parse(node) function
it will set link label as new URL.
- For that we add condition by which it will avoid further operations and Now
when we try to edit link mailto then there is no "https://" added and link
works successfully.
Task-2977682
closesodoo/odoo#108639
X-original-commit: 680a204b952e6281d7e1bcdfe0730688ee698a9d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, changing the font size of an element with one
ancestor having the same font size could trigger a traceback. For fixing
that issue some code has to be refactored to handle the setFontSize case
in formatSelection. As a side effect of this refactoring, nested
font-size is now properly handled (see added tests).
task-3086301
closesodoo/odoo#108633
X-original-commit: d003b82043468bcf609006c5910ac8fc9520e136
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
the readonly field reversed_entry_id in account.move model is always visible in the form view in the journal entry screen. adding the invisible condition to hide the field when the field doesnt have value in it.
closesodoo/odoo#108006
Signed-off-by: Laurent Smet <las@odoo.com>
In this commit, we have removed the multi-GSTIN feature from the journal.
Multi-unit is created if there is a different branch with the same GSTIN(vat) so
now we decided to create a multi-company instead of this.
because functionally we discuss with Indian CA and we find out that it's good
practice if we create a different company.
The main problem is one company and the same Bank account but we also find a
functional solution using a transfer balance to another company.
so we remove this so our other integrations do not have complexity
like E-invoice, E-waybill, GST E-filing
TaskID - 2723109
closesodoo/odoo#107234
Related: odoo/upgrade#4107
Signed-off-by: Josse Colpaert <jco@odoo.com>
Breaking on 2022->2033 transition
Those tests should be adapted to work without hardcoded dates.
closesodoo/odoo#108884
X-original-commit: 6945966b49a58ce3c0976dce37e324b37af8367a
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
With the new year transition, some demo data relative to the current
time are now inconsistent with each others:
- Some payslips starts 2 mount before now.
- the contract starts this year, first January.
This means that
- the contract starts 2023-01-01
- the payslips ends 2022-12-01
Leading to an error
"The following employees have a contract outside of the payslip period"
Note that it looks like there is a also a demo/admin inconsistency
in data but this is out of the scope of this fix.
X-original-commit: ae259f93b6ccaaec17a8d32df6282278e015c395
Part-of: odoo/odoo#108884
Current behavior:
If you add cash at the opening of a session that already has cash in the
cash register; the closing popup will show a negative profit (loss) for
the cash payment method.
Steps to reproduce:
- Open a POS session
- Add cash to the cash register (50€)
- Close the session
- Open a new session
- The popup show that there is already 50€ in the cash register, add
cash to the cash register (100€)
- Close the session, the closing popup will show a loss of 50€ for the
cash payment method. Wich is not true, it's a profit of 50€.
opw-3101297
closesodoo/odoo#108870
X-original-commit: d881de9079bc9d8cab6811872eaa2c2138f6612d
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Before this commit:
If you make a PoS payment using a Stripe terminal, you will have
the following JS Traceback:
```js
TypeError: Cannot read properties of undefined (reading 'data')
at Proxy.captureAfterPayment
```
This happens on the line:
`capturePayment.charges.data[0].payment_method_details.card_present.brand;`
It occurs as Stripe API most recent version does not provide the
`charges` value anymore.
> The charges property on PaymentIntent has been removed
source:
https://stripe.com/docs/upgrades#2022-11-15
After this commit:
We skip the data if not mentioned on the JS side.
In addition of that, we use the `_stripe_make_request`
method of the Stripe payment provider as it
force in its header to use a certain Stripe API version
compatible with the features that we are looking for.
opw-3097460
closesodoo/odoo#108851
X-original-commit: 6a6057caf63d7e6a60dac190b2ea1ebb954d8f6a
Signed-off-by: Loan (LSE) <lse@odoo.com>
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
The eta.gov.eg production servers can't be connected using OpenSSL 3.0.
This is happening because of the change in:
https://github.com/openssl/openssl/commit/72d2670bd21becfa6a64bb03fa55ad82d6d0c0f3
that now by default prevent unsafe legacy renegotiation that eta.gov.eg
is using.
To prevent this issue, we add the SSL_OP_LEGACY_SERVER_CONNECT option to
ssl context of queries to the eta.gov.eg servers.
SSL_OP_LEGACY_SERVER_CONNECT is not available before python 3.12, so
the value is hardcoded in Odoo.
opw-3102485
closesodoo/odoo#108848
X-original-commit: 0ae8c55ff2db8810a990407e706c4c86b221d4c4
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
After [1], most snippet options should use something like
`this.$target[0].ownerDocument` to access the document properties
instead of the global object `document`. This is because the editable is
now inside an iframe.
Commit [2] tried to adapt most occurrences but missed some.
This commit adapts the leftover code and fixes 2 bugs:
1. The SCSS Variable `font` wasn't properly reset when deleting a Google
font that was currently being used, resulting in a `/` being displayed
and the variable having an inconsistent state.
2. In the Chart snippet, the color being used to represent data is
displayed inside the option as a border on the input widgets. It was
currently using Odoo's colors instead of the ones defined in website.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af
task-2978623
X-original-commit: 6e0bd78e59b8352d15c9f21bf5f891924d6c3c9f
Part-of: odoo/odoo#108819
Steps to reproduce:
- Drop enough snippets to have a scrollbar.
- Drop a snippet with inner content having up/down arrows (e.g.
showcase,timeline).
- Move inner content with the arrows.
- => The element is correctly placed but the screen scrolled along
with it.
This commit fixes it by preventing the page from scrolling if the
element being moved is still visible after the move. The page therefore
scrolls only if the moved element is not visible after the move.
This commit also improves page scrolling when the element is hidden at
the bottom. Before, the page scrolled to bring the moved element to the
top of the page but now, it stops scrolling as soon as the element is
fully visible.
task-2952200
closesodoo/odoo#108831
X-original-commit: 675ae44803539a807c79fbc32c93b4e5d230816e
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
Since #107916, the ActivityModel did not include
`["activity_ids", "!=", false]` in its domain, causing incoherence in
some views and resulting in crashes.
To reproduce the issue:
- In the runbot, navigate to Website -> eCommerce -> Product.
- Switch to the activity view.
- Remove the Published filter.
- The view crashes due to an incoherence between the data records
in the `web_search_read` and the `get_activity_data` calls.
This commit resolves the issue by correctly setting the domain.
closesodoo/odoo#108807
Signed-off-by: Luca Vitali <luvi@odoo.com>
Commit [1] made the "light" and "dark" colors of bootstrap be very
light and dark variations of the "main" color ("alpha" at the time, now
"o-color-1", which is used as bootstrap "primary" color). It was already
not a very good idea, although slightly better than nothing (at the time
navbar and footer colors could not be changed at all, so without this,
they would use a gray with a blueish hue not related to the main color).
Since then, 2.5 years later, [2] and [3] were made which gave some
control over bootstrap default grays via two widgets controlling the
new "gray-hue" and "gray-extra-saturation" params. At that time, the
light and dark overrides made at [1] should have been removed as "light"
and "dark" normally default to two bootstrap grays, which we would have
had control over since [2] and [3]. This was however, not a big problem
since "light" and "dark" were not used by the website templates (well it
was by some but not a lot) and the overrides to gray colors related to
the main color was not "stupid", just less nice as less control over it.
However, since the many improvements made with [4] more than 1 year
later, the "light" color started to be used to achieve more detailed
designed for the eCommerce. And it is planned to use it in further
design elements later on. The fact that those "light" elements are not
following the "grays" configuration made by the user is thus starting to
be a problem.
This commit fixes the issue in master (>= 16.1): "light" and "dark"
colors will now follow the configured grays. In the future, we might
even improve the control over those two particular grays or maybe
improve their default value according to the theme color palette.
It was judged that stable versions can stay as they are right now. As
explained, it is not critical and you can still force your own CSS rules
if you are really unhappy with the "hardcoded" grays (related to the
main color) at some places.
[1]: https://github.com/odoo/odoo/commit/22c4311e283af95eafe1ba85ee1234bb8102110e
[2]: https://github.com/odoo/odoo/commit/35d27a6c1d3dab621de7f059565d7619ae004412
[3]: https://github.com/odoo/odoo/commit/e08184103c42eaf7f6bfb70655cb90b51e79913a
[4]: https://github.com/odoo/odoo/pull/98558
Related to task-3097005
closesodoo/odoo#108825
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When `link_tools` was introduced at [1], `_onURLInput` did only update
the configuration form and did not touch the edited DOM. Even though its
name would be misleading for that purpose, it was therefore used without
issue as an event handler responding to the configuration form input
events and as a private method called in the `start` method of the
widget lifecycle.
At a later stage, with [2], DOM modifications were introduced in
`_onURLInput` (using the misleading `_adaptPreview` method whose
refactoring at [3] made it update the configuration form only in the
case of the "Link Dialog" but update the actual link DOM for the "Link
tools" (website / mass mailing)).
This commit fixes that behavior by touching what is strictly necessary
in stable to keep the original intend of `_onURLInput` (updating the
configuration UI) but at the same time update the DOM following
configuration form input events (as intended by [2]).
In master, all of this should be reviewed.
Here are steps which revealed the problem. Although, meanwhile, [4] and
its parents were merged which fixed other parts of this issue but
keeping the potentially problematic DOM update on selection as described
above. Notice that [4] and its parents may be reviewed further in a
future update.
- Edit Home page
- Drop a "Banner" block
- Select the "Contact Us" button
- Select "Custom" style in the link tool
- Select a fill color
- Deselect the button by clicking on the Banner's text
- Select the button again
=> Button is redrawn without its color
[1]: https://github.com/odoo/odoo/commit/740168ce8d27da3d6a7156d2d79655a898394923
[2]: https://github.com/odoo/odoo/commit/226c4c4032c26d3d8f622b29fb151fa8e78ba70a
[3]: https://github.com/odoo/odoo/commit/4a1d776243b059d423152bd026bb8bc758477224
[4]: https://github.com/odoo/odoo/commit/eb4edac560227b46efdcfe958e3b93e0b88def64
opw-3086198
task-3096806
X-original-commit: da25eadde299b81b78d84678978b7e1f703530cc
Part-of: odoo/odoo#108812
Co-authored-by: qsm-odoo <qsm@odoo.com>
In the BoM Overview, routes were always displayed regardless of the
display options selected in the filter. Since lead times are only
relevant when checking their associated routes (as they determine them),
it makes sense to add the display of the routes in the lead times
filter.
closesodoo/odoo#108808
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
A traceback was shown when 'None' background was chosen to configure the
onboarding panel's background image (css class).
Supposing no one built anything with a `o_onboarding_False` class, we also
clean the result for a `False` value while we are here.
Task-3104723
closesodoo/odoo#108801
X-original-commit: 8a8da706e55073c48aa3cdc21201b4552230de87
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This commit disables the submit button on the survey main form during loading.
This is done to avoid the user clicking on the submit button *before* the
JavaScript code is loaded, which will by default trigger a page reload.
That situation can happen on slow connections, and as it reloads the page, the
user keeps clicking on "start" and it keeps reloading, creating frustration.
Task-3111551
closesodoo/odoo#108802
X-original-commit: cb12745329177812bd48ac5520044069ed6ecb9e
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The revision 65a012c2bba0ed81d9b525a7779c726043b17707 changed the
behavior of method _read() when invoked on a record with id None.
Before the change, the method would consider that no records have been
fetched because the id is falsy. After the change, it keeps the id None
in the fetched records, and attempts to make subsequent SQL queries like
"column IN ()", which is syntactically incorrect.
OPW 3104957
closesodoo/odoo#108785
X-original-commit: 712d03cb2ee5f2fde0e80619be5db38aa09ed1ac
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
Thomas Lefebvre (thle)