If a user has a website.track with a product from another company than
the one he is currently using, an access rule error will popup.
Several scenarios can trigger this error, but the easiest one would be:
- Activate recently viewed products in the e-commerce.
- Create a product and publish it.
- The portal user visits it and a website.track linked to that product
is created.
- From backend, change the company of the product to one that is
unreachable for the portal user or the website environment he is in.
- Now when the portal user visits another product, an error will show up
warning about the unability to load the recently viewed product.
So only products in the context of the request should be loaded as
recently viewed.
TT36698
closesodoo/odoo#93589
X-original-commit: bded9cc3649e0178d95452d5ef861285d5558478
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
When the duration of an approved time off is changed from the time off dashboard,
the holiday_status_id field is no longer editable in the form, only the duration of the leave.
This causes a traceback due to the custom form controller to update the name of the time off type
based on the allocations available.
closesodoo/odoo#93858
X-original-commit: b87e672e1e5367d774dee2de6a7c76374cc2da39
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: phwa-odoo <phwa@odoo.com>
Before this commit, when we use a domain list made by the old
implementation of the Domain in js and in this domain we have a date in
a right leaf then this date is an object of Date class. However, with
the new implementation of the Domain, the date will be converted into a
PyDate/PyDatetine object and so when we create a domain with the new
implementation by giving a list containing the result of the old
implementation. The date will be converted as a plain object instead of
a date formatted or instead of a date object.
This commit converts the list in string before using `Domain.and` with
the new implementation to having a date formatted as a string to avoid
the issue.
for instance, when the user choose a filter containing a date in the
right of a leaf in the domain. The old implementation of domain class
will return `[['date', '=', new Date(1970, 1, 1)]]`
```js
new Domain([['date', '=', new Date(1970, 1, 1)]]).toList()
// result: [['date', '=', {day: 1, month: 1, year: 1970}]]
```
if the list is converted as a string before passing the result will be:
```js
new Domain(JSON.stringify([['date', '=', new Date(1970, 1, 1)]])).toList()
// result: [['date', '=', '1970-01-01']]
```
closesodoo/odoo#93884
X-original-commit: 44d4a44dc4695b40a52c7d4cfccf0e9238d39b19
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
Before this commit, the link "Manage Databases" was present in the
/web/reset_password screen, even if it is disabled.
Fixesodoo/odoo#93678closesodoo/odoo#93881
X-original-commit: 3a1f41f2c42957a10cdd96a59c62ddd83fbdecd8
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
*: website_sale_loyalty
After this commit, the "show # found" option of the search bar is no
longer available for users. The "show # found" is now always displayed.
It was actually a strange option in this first place as it was only
available when website_sale was installed but actually impacted all
other apps.
Related to task-2710582
closesodoo/odoo#93817
Related: odoo/upgrade#3601
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Since this commit : 7d69a28f0710ffc27979f6e977997f972bc129bb,
the add_banner() method is no longer executed,
which disables a recently added feature (see here : https://github.com/odoo/odoo/pull/84542).
The goal here is simply to restore it.
closesodoo/odoo#93860
X-original-commit: 29d3d5a3b5286fa6db625b3910ad325ed84472d8
Signed-off-by: Laurent Smet <las@odoo.com>
Currently, the name of products of the type 'course' in SOL was missing
due to the split by '\n' in name_get.
So this commit fixes this issue and remove the \n if there is
only one payment channel for course.
task-2823432
closesodoo/odoo#93836
X-original-commit: 289c3219b7975ebee8748223a136e1d752da440f
Related: odoo/enterprise#28499
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
When submitting a rating without submitting a feedback, the value of the field "rating_last_value" is not updated, because the rating values are not yet updated in the database when the method _compute_rating_last_value is called.
Steps to reproduce
------------------
The following steps are for an helpdesk ticket, but it should behave the same way on all models implementing the rating mixin.
1. Create a ticket in a team with a stage with the default rating email template.
2. Move it to the stage with the template (it should create a rating email)
3. Use the email to submit a rating.
4. When you get to the feedback page, close it without doing anything.
5. Go to your ticket's form view => the rating you submitted correctly appears in the stat button.
6. Go back to the team, and filter tickets by "No Rating" => your ticket appears, despite having a rating.
Expected behavior
-----------------
The field "rating_last_value" should have the value of the last rating submitted.
Technical
---------
This commit adds a flush right before the SQL query in `_compute_rating_last_value` to make sure the rating values are up to date in the database before the query is executed.
It also updates the test for rating submissions to also check the rating_last_value, and creates a new test for the route currently used in the first step of a rating.
Task-2880707
closesodoo/odoo#93846
X-original-commit: 2b3b840cdb2721759552c6b0003bcd2a69c9b34f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Larcin Vincent (vila) <vila@odoo.com>
PURPOSE:
- Add no content helpers in the favorite and member views, as well as
on the main "article" view: when no article exists, a smiling face
suggests to create one, when no favorite relation exists, a smiling
face suggests to add an article to the favorites and explains how to
do it, and when no member relation exists, the purpose of creating
one is explained.
- Add samples in background when there are no records in the members
and favorite views.
- Set the member and favorite list views as editable=bottom to allow
modifications from these views since these models are simple.
- Allow users to search for articles based on their content.
- Make the favorite and member views open to admin users in debug mode
only, instead of all internal users in debug mode.
- This commit slightly modifies the content of the onboarding data
articles: some paragraphs have swapped their position, typos have been
fixed, downloadable files have other names or content, advanced features
paragraph is more detailed, all with the aim of improving the user
experience.
- It also prevents data articles to reappear when upgrading the module
after that they have been deleted: if one deletes a data article, it
should behave the same way as for a regular article and this article
should be deleted forever.
These additions have been made with the aim of improving the user experience.
Task-2852946
closesodoo/odoo#93834
Forward-port-of: odoo/odoo#93690
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
PURPOSE:
- This commit slightly modifies the content of the onboarding data
articles: some paragraphs have swapped their position, typos have been
fixed, downloadable files have other names or content, advanced features
paragraph is more detailed, all with the aim of improving the user
experience.
- It also prevents data articles to reappear when upgrading the module
after that they have been deleted: if one deletes a data article, it
should behave the same way as for a regular article and this article
should be deleted forever.
Task-2852946
X-original-commit: 9e2b29fdd10e240947e350d569d9c2347dddd72e
Part-of: odoo/odoo#93834
PURPOSE:
- Add no content helpers in the favorite and member views, as well as
on the main "article" view: when no article exists, a smiling face
suggests to create one, when no favorite relation exists, a smiling
face suggests to add an article to the favorites and explains how to
do it, and when no member relation exists, the purpose of creating
one is explained.
- Add samples in background when there are no records in the members
and favorite views.
- Set the favorite list views as editable=bottom to allow
modifications from the list view.
- Remove the sequence handle in the favorite list view to prevent
reordering, because it led to strange behaviors since the favorite
articles are ordered by user id.
- Disallow users to create or edit records in the members view, as
creation and edition are normally handled by custom methods, that won't
be triggered when creating or editing from this view.
- Allow users to search for articles based on their content.
- Make the favorite and member views open to admin users in debug mode
only, instead of all internal users in debug mode.
These additions have been made with the aim of improving the user
experience.
Task-2852946
X-original-commit: 1e9fcafa59c421607d781d2fc4b760598ed2e3fb
Part-of: odoo/odoo#93834
The table ir_module_dependency was created manually with tracking fields,
but the CRUD was done manually, without the ORM.
Removing the fields that are always null will not have any impact
whatsoever but we should still do it to be correct.
closesodoo/odoo#89268
Related: odoo/upgrade#3455
Signed-off-by: Rémy Voet <ryv@odoo.com>
Steps to reproduce
------------------
1. Install project and fsm.
2. Enable a basic project feature (sub-tasks/task dependencies) in the settings.
3. Enable the same feature on the fsm project.
4. Disable the feature in the settings.
5. The feature is still enabled on the fsm project
- This can be hard to see since the field will be hidden on the settings of the project, but you can see that the "Sub-tasks" tab is still visible on tasks if you enabled sub-tasks.
- Also, when re-enabling the feature globally, it should be disabled for the fsm project, but won't be.
Expected behavior
-----------------
The feature should be disabled on all projects, including fsm ones, when disabling it globally
---
This commit fixes this bug by selecting all projects, and not just basic ones,
when disabling a basic feature globally, to disable that feature on all projects.
Related: https://github.com/odoo/enterprise/pull/28036
Task-2871448
closesodoo/odoo#93820
X-original-commit: 84f8957533e85672d3b17d1a9004193b091f9fea
Related: odoo/enterprise#28488
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Larcin Vincent (vila) <vila@odoo.com>
To reproduce
============
- on a database where *sale*, *contacts* and *website_sale* are installed
- create a user without sales access rights but has the right to create a contact (extra rights/create contact)
- connect to this user and try to create a contact
An Access Error is raised.
Purpose
=======
Because the model *website_sale* is installed, the method `_onchange_property_product_pricelist` in `res_partner` is triggred.
In this method we run `search` on `sale.order`, but the user doesn't have the right to read `sale.order` so the error is raised.
Specification
=============
The role of the method `_onchange_property_product_pricelist` is needed when we edit an exisitng contact,
but in our case, we are creating a new one.
To solve issue, the method `_onchange_property_product_pricelist` has been modified to do nothing in case of new contact.
opw-2864945
closesodoo/odoo#93813
X-original-commit: 0c49d86f4fac18d151bbda95cbe29bcb1dc9481d
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
At the moment, if we try to make a website field conditionally visible
based on whether a file has been uploaded, the field never appears even
after uploading the file.
Steps to reproduce issue
- Create a new fresh DB with the website app.
- Go to the Contact Us page, click on 'Edit'.
- Add a File Upload field
- Add another field, and set it to be conditionally visible on the
File Upload field.
Fix:
- Create visibility comparators for files (fileSet / !fileSet), which
check whether the `value.name` property is set / not set.
opw-2856054
closesodoo/odoo#93756
X-original-commit: fec02f6cfc4abd68f0d6bd49285580510fe59465
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
When attempting to run the Odoo server on macOS Monterey (currently
12.4), it crashes with the following traceback:
```
Traceback (most recent call last):
File "/Users/app/Code/odoo/odoo-bin", line 8, in <module>
odoo.cli.main()
File "/Users/app/Code/odoo/odoo/cli/command.py", line 61, in main
o.run(args)
File "/Users/app/Code/odoo/odoo/cli/server.py", line 179, in run
main(args)
File "/Users/app/Code/odoo/odoo/cli/server.py", line 173, in main
rc = odoo.service.server.start(preload=preload, stop=stop)
File "/Users/app/Code/odoo/odoo/service/server.py", line 1342, in start
rc = server.run(preload, stop)
File "/Users/app/Code/odoo/odoo/service/server.py", line 553, in run
self.start(stop=stop)
File "/Users/app/Code/odoo/odoo/service/server.py", line 491, in start
set_limit_memory_hard()
File "/Users/app/Code/odoo/odoo/service/server.py", line 83, in set_limit_memory_hard
resource.setrlimit(rlimit, (config['limit_memory_hard'], hard))
ValueError: current limit exceeds maximum limit
```
Actually, this issue is not specific to Odoo but affects Python on macOS
as a whole (see [1] and [2]).
As our memory management is based on Linux - which is our primary
deployment target - and non-POSIX systems were already excluded, this
commit escapes the rlimit modification on non-Linux systems to prevent
this kind of issue.
References:
[1] https://bugs.python.org/issue34602
[2] https://github.com/python/cpython/pull/14546
Related issue:
https://github.com/odoo/odoo/issues/79112closesodoo/odoo#93381
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Steps to reproduce the product:
- Create a new product:
- Select “Service” type
- Go to the Sales tab:
- Select "Create a task in an existing project" in the `service
tracking` field
- the `project` field becomes visible
- Change the Type of the product to “Consumable”
- Try to save
Problem:
The field `project` remains visible and as it is a required field,
we have to fill it in before being able to save the product.
While it is a feature only for service-type products
Solution:
- The `project` field is based on the `service_tracking` field
to become invisible or not. So when the product is not of service type,
we must remove the tracking service so that the project field
becomes invisible.
- Prevent the user from changing the type of products already used in
a sale order
opw-2858064
closesodoo/odoo#93804
X-original-commit: 102951140e3f35ced8653d4bedb82b63bb2c963f
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
The mock implementation of search_count returns `false` instead of 0 when the
domain doesn't match any records.
Also, writing some tests revealed the `active_test` context key was not taken
into account.
closesodoo/odoo#93746
Related: odoo/enterprise#28449
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this fix, when clicking on the delete button from the product screen, when the decrease quantity popup was supposed to be shown, there was a null value issue and thus a traceback.
With this fix, we force the value to be 0 instead of null.
closesodoo/odoo#92854
Signed-off-by: Masereel Pierre <pim@odoo.com>
Currently, the module l10n_fr_pos_cert (France - VAT Anti-Fraud Certification):
Prevent price modification
Prevent from inserting negative lines while decreasing quantity
Hash links between orders
Print the hash onto the ticket
This commit allows the price modification of the products.
To be compliant with the law, we track any price modification on the ticket and on the product screen.
Task-id: 2610576
Part-of: odoo/odoo#92854
The overridden method was not properly renamed and converted, with this fix we can now filter orders
based on their table.
closesodoo/odoo#93790
X-original-commit: cf8cf179914435b48c1698f8c873bdf2f0a566b6
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
When a field in a form has a conditional visibility, its potential value
is not sent once the form is submitted if the conditional visibility is
not met. Before this commit, that was not the case for file fields.
Steps to reproduce the bug fixed by this commit:
- Drop a form or go to /contactus
- Add a file field
- Put a visibility condition on this field and save
- Fill the form, respect the visibility condition you have introduced,
add a file in the previously added field.
- Before submitting the form, make sure the visibility condition is no
longer met and then submit the form.
Your file is part of the submitted data by mistake. As it was hidden at
the time you submitted the form, it should not have been sent.
opw-2856054
closesodoo/odoo#93783
X-original-commit: 159106bf873b866b9ce93e48a45f7d1d9346aa45
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This works follows [1] which already hid lots of options which were not
supposed to show up on some images. That concerned mainly t-field images
and others. This commit is about media elements (images, icons, ...)
which are editable roots, meaning they carry the branding of the portion
of the view they belong to.
In 14.0, such root media elements were simply not editable. Indeed, the
media tools (which were amongst text tools of summernote) simply did not
show up. With the new editor of 15.0, all media options were converted
as "snippet" options for the website editor. The system being entirely
different, explicit conditions for the options to not appear had to be
made.
Technically, some of those options may work on editable roots. With [2],
the "class" and "style" attributes are savable on such items... unless
they are computed. In the future, we may allow more attributes. The
problem in allowing some options to appear (depending if they work on
a given element) is that it would require:
- knowing which attributes an option modifies (class? style? others?)
- knowing which attributes are computed in the qweb view
We may consider improving all of that in future versions, but in stable,
we decided to simply hide all media options on editable roots.
Theoretically, some non-media options could still appear on non-media
editable root elements and not work... but probably no standard option
matches this case.
[1]: https://github.com/odoo/odoo/commit/e707789d43a5754dc2a28192e5502cc14eaca73f
[2]: https://github.com/odoo/odoo/commit/8579c0cae839c615415120b79d6ec22c71f7affd
opw-2817765
opw-2854285
opw-2864584
closesodoo/odoo#93751
X-original-commit: 9dc76ce4b0a646563a29a431e28cf96218a66991
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
issue: The debug-assets didn't work anymore. The t-cache placed on the
header allowing not to redo this one for each rendering did not depend
on the debug mode.
closesodoo/odoo#93590
X-original-commit: 3061a484168ff21e3ae7e40ce691d299b63484a4
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Christophe Matthieu (chm) <chm@odoo.com>
The getAll and getEntries functions have a cache, i.e. the array
they return is lazy evaluated once, and then kept until the next
update of the registry. Before this commit, those functions
returned their own version of those arrays, not a copy. As a
consequence, someone that would modify those arrays would actually
modify the arrays in the cache, and every subsequent calls to those
functions would return those modified arrays, which would not
correspond to the actual state of the registry.
closesodoo/odoo#93767
X-original-commit: c3d0449bb09a012d9ce97bfc6401476cf8a57c26
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Chrome did an update on which LAN devices are not accessible trough websites (but would still be accessible in `localhost`) ending in CORS error when trying to reach the device. More information:
https://developer.chrome.com/blog/private-network-access-update/
Before this commit:
A lot of customers were confused as of why their printers suddently stop working without any changes.
After this commit:
The error message have been improved to also guide people to solve this issue (creating an HTTPS certificate).
Note that it is not possible from the JS code to say if they are concerned by this issue or not as the error given does not specify explicitly if it is a CORS error or something else, see:
https://stackoverflow.com/a/6734427
OPW-2850019
& many more like:
OPW-2856164
OPW-2858658
OPW-2857076
closesodoo/odoo#93764
X-original-commit: e97b14f2bfe3d8b096b42c6bc3cf35537367aff7
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
(i.e. orden de compra, guia de despacho) if they are enabled
closesodoo/odoo#93763
X-original-commit: afde2ab2cd44078b812e3fdd1553a55650fa45c0
Signed-off-by: Josse Colpaert <jco@odoo.com>
Previously, when importing both the default export and named imports
with a trailing comma, we would transpile into an object where the first
keys were the named imports, including any trailing comma, and
concatenating with the default import with a leading comma, this means
that the trailing comma would transpile to two successive commas which
is not valid syntax.
This commit fixes that by putting the default import first, and adding
the named imports after, preserving the trailing comma if any, but
precluding the possibility that we get two commas back to back.
closesodoo/odoo#93693
X-original-commit: 798d2f2c6e8a496f4ce0cd3c4f1609693e692254
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Purpose
=======
It becomes unclear what the button does once the search view doesn't
filter on the related job's applications (aka the filter is removed
for example)
Taskid: 2884356
Part-of: odoo/odoo#93684
After opening the configurator wizard in "edit" mode (through the pencil
icon shown next to the product in edit mode), if you clicked either on
the "Cancel" button or on the "X" to leave/close the wizard,
the product was reset on the SOline.
Cancelling a modification should keep the state before the modification and
not reset the line.
This is a regression from the behavior in saas-12.3.
closesodoo/odoo#93666
X-original-commit: 0f0d3a20910d20221f9b80fc290f743091ecd8b7
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Follow-up of https://github.com/odoo/odoo/pull/93330
Commit above renamed "MediaPreview" to "CallDemoView".
However, it mistakenly did not rename the SCSS rules that
referred to `o_MediaPreview`.
As a result, some styles were no longer applied, like buttons
being an overlay on top of camera stream.
closesodoo/odoo#93724
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit ensures that, when creating a private task, the current user
is always part of the assignees.
This commit also adds tests on the different `project.task` creation scenari
to ensure it gets not broken in the future.
task-2818486
closesodoo/odoo#89041
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, it was possible to assign a non-personal stage on a private task,
which is a nonsense as the task does not belong to a project. Only personal stages
should be set to a private task.
After this commit, if a non-personal stage is set on a private task, a UserError is raised.
task-2818486
Part-of: odoo/odoo#89041
Current design, especially related to views in small viewports, has
been revamped in order to increase readability and to be more coherent
with the one in large screens.
Task-2813949
closesodoo/odoo#87915
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Current SCSS is replaced with global Bootstrap classes, in
order to reduce code lines and to increase performance.
Task-2813949
Part-of: odoo/odoo#87915
Current behavior:
If you stay in idle too long on the payment screen while doing a
payment the screen would go back to the floor screen
Steps to reproduce:
- Have PoS installed and setup restaurant
- Go in the PoS restaurant
- Go in any table add some product and go to payment screen
- Click on any payment method
- Wait some time and you should go back to the floor screen
opw-2849939
closesodoo/odoo#93689
X-original-commit: 3c90b940e4ffa9208517974a6238e64e09f03475
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Task 2843455
When an exchange difference is linked to a payment, not an invoice,
it is not displayed in the payment widget even though an exchange
difference move is created and matched with the invoice.
Exchange difference should be displayed when it's linked to the payment as well.
closesodoo/odoo#92069
Signed-off-by: Laurent Smet <las@odoo.com>
For the kanban_activity view (e.g.: in the CRM module), when we have enough
entries to require the scrolling, dropdowns are not displayed at the correct
location.
Furthermore, in kanban views, when dropdowns are opening on the edge of the
parent element (e.g.: in Documents), the dropdowns are partially hidden and not
accessible by the client.
Step to reproduce the issue:
1) Install CRM and Documents module
2) Go to CRM and create multiple leads with at least one activity
3) Go to the Activity view and scroll down and click on an item. The dropdown
is not placed at the correct location -> BUG 1
4) Go to the Documents modules and check the activity (the small clock icon)
of a Document on the right most column. The dropdown is hidden by the
description of the file.
Solution: Firstly, the parent container of the Kanban Activity view did not had
the `overflow: auto` property activated. Consequently, while the children were
somehow taking all the spaces of the screen, Popper (the third party that
handles the dynamic positioning of the dropdowns) was wrongly computing the
positionning.
Secondly, dynamically creating the dropdown via Javascript (through the
JQueryInterface of the Dropdown class in Bootstrap) somehow allows to fix the
issue in Documents. Consequently, it is important to keep them into the
Javascript and not move the arguments into the XML.
opw-2827873
closesodoo/odoo#93661
X-original-commit: 38fa6a70b70dac0d511be7952c496a5178f9c40e
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
david