Before this commit the "Thanks" button of the newsletter block could be
saved as visible. This meant that a visitor who did not subscribe to the
newsletter would see the "Thanks" button on loading before it
disappeared. This commit solves this problem by:
1. hiding the "Thanks" button before saving
2. having an option to show/hide the "Thanks" button in edit mode
3. hiding the "Thanks" button before switching to edit mode
Steps to reproduce the fixed bug:
- Drop a newsletter block.
- Save and register to the newsletter.
- Edit
- Change anything in the newsletter block.
- Save and Logout.
- Now the Thanks button appears and disappears when the page is loaded
opw-2802139
closesodoo/odoo#94002
X-original-commit: 57793ff912ac5aab8f3d3e014992965d06290bf0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Avoid leaks in case of exception.
closesodoo/odoo#93993
X-original-commit: 1a1a10b7ce53f24eabed3e3a38f34b354d2d1911
Signed-off-by: Christophe Simonis <chs@odoo.com>
The call to `commit()` can fail during the flush of the environment
and raise an exception before the actual `COMMIT;`, leaving the
cursor unclosed.
This leaked cursor may hold locks that only be released when the GC
collects it. On low-traffic workers like the CronWorker, this can
lock usual database usages.
X-original-commit: 3cb3cec67c28ca147288103adb219e6da8694248
Part-of: odoo/odoo#93993
Purpose
=======
In message_notify, when called on a recordset, call model methods instead of
base one defined on MailThread. This allows to use internal methods overrides.
Also perform some linting on calls to ``message_notify`` in order to better
spot calls, parameters, ...
Task-2852908
closesodoo/odoo#92868
Related: odoo/enterprise#28038
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When fetching recipients information for user_notification we don't need to
check for followers, as only explicit recipients are considered.
Task-2859935
Part-of: odoo/odoo#92868
Install website and website_hr_recruitment, open /web with ?debug=1, go
to website > configuration > redirect, create a temporary (302)
redirection from `/jobs/detail/experienced-developer-4` to `/404`. Open
the `/jobs/detail/experienced-developer-4` as admin and unpublish the
page. Open the same URL via private browsing (so that you are not
connected), you get the default 403 - Forbidden page, you were not
redirected to the 404 - Not Found page.
Custom 301 (permanent) and 302 (temporary) redirections are fallback
redirections when the requested page does not exist or is not accessible
to the current user. The HTTPocalypse broke the later case, it was not
checking for existing redirection upon access error.
The use case is the one supported with [1] where people want/need to
display something better than a 403 when they unpublish a record like a
job position for instance (most of the requested cases on opw).
Indeed:
- People have link to that record/job everywhere on the internet
- The job position / record is no more relevant, and people need to
unpublish it
- People don't want to delete it (or can't sometimes due to record
relations)
- People don't want visitors to land on a 403, mainly because it is a
non customizable advanced/technical page (it displays a technical
message including the record name etc)
- Their need is to either land a their customizable friendly 404 or
sometimes on another record to promote it.
[1]: https://github.com/odoo/odoo/commit/3b9cd536607b1631dd375ab2e5cc94eb814a6e9bclosesodoo/odoo#93981
X-original-commit: eb7eecec976570ae3301c17a04adc9c110d5b14a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Julien Castiaux <juc@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
*: website, test_website
Since [1], a race condition seems to have become more dominant. It is
actually due to a tour not properly awaiting the editor to be loaded
before using it.
This commit fixes all occurrences of such 'trigger' selectors, even in
tours were it could actually be not a problem. That will prevent devs to
copy paste the problematic trigger.
[1]: https://github.com/odoo/odoo/commit/57793ff912ac5aab8f3d3e014992965d06290bf0closesodoo/odoo#94000
X-original-commit: 38f3a94263b9cf48e9f5a8de553b8602310bcddd
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When adjusting the currency rates, the amounts in the edi invoice become
incorrect and the Italian EDI system rejects them (due to contraints on
the content of these fields).
This commit changes the referenced amount to the 'amount_currency' (for
the taxes and the base) for the fields in the EDI templates.
closesodoo/odoo#93991
X-original-commit: 34315a9114eff6fa8ce3b16bb081ad026816a08c
Signed-off-by: Josse Colpaert <jco@odoo.com>
*: website_livechat
This commit is a step towards refactoring the JS of public livechat,
so that it reuses the same architecture as the code of Discuss.
This implies code that uses JS models and OWL components.
Task-2887296
closesodoo/odoo#93966
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
In commit d4b046e238, a sudo was lost,
leading to 403 errors shown to public users browsing the ecommerce.
closesodoo/odoo#93947
X-original-commit: 96f491dafe9b247638db04ecfb33f3dbbc36e73c
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Currently, certain fields take the decimal accuracy of the product_uom
whilst other's don't follow this logic.
This causes a discrepancy between the decimal accuracy of all fields
where there should be none.
The purpose of this commit, is to stay consistent across all fields in
the view.
closesodoo/odoo#93935
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Journal items:
- 2 list views were available for the journal items. As these changes
make them very similar, the "grouped" view is dropped and only
the simple/normal list view is used.
- As the usefull information is now available from the list items,
the more complex name that was previously used on the group by
lines is not useful anymore.
- Removed duplicated filters.
- Added and modified columns of the list view.
- Removed the button opening the move form from the move line, and
made the move name clickable (with same behaviour as the button).
- Removed edit button on some group by lines, as it can lead to
unwanted access errors.
- Removed 2 filters and added 1.
- Added a field to use for the matching widget.
- `move_id` was replaced by `move_name`, because the sorting of the
Many2One `move_id` is not based on its name and was thus not
working as intended.
task 2855459
closesodoo/odoo#93586
Related: odoo/enterprise#28361
Related: odoo/upgrade#3598
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
In this commit, added test of timesheet analytic tags
Test Case:
--------
1. Create analytic tags
2. Add analytic tag in project
3. Create timesheet
4. Check the default analytic tag of the project and timesheet
5. Add analytic tag in task
6. Check the analytic tag of the timesheet and task
task-2878938
closesodoo/odoo#93214
Related: odoo/enterprise#28209
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The project privacy_visibility tooltip doesn't reflect the actual behavior
for the "Invited portal users and all internal users" selection.
This commit rephrases the tooltip of that field in order to correctly match its behavior.
It also slightly changes the name of the options to match the new tooltip.
Task-2871771
closesodoo/odoo#93911
X-original-commit: 9ef7030e3346eda267bc27b47a8a168acdc4a7b9
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The lack of a div container between the 'page' div and the payment
terms/note/fiscal position section made it impossible to add blocks
at the end of the report, after these elements.
opw-2885434
closesodoo/odoo#93893
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Website has no dependency to web_unsplash, we cannot warranty the order
of the execution of the overwrite done in 5ef8300.
So to avoid to create a new module bridge, with a lot of code, we prefer
to make a check for website user directly in unsplash module.
It is 'safe' since if you don't have website, the group
`group_website_designer` doesn't exists and so it will do a `or False`.
closesodoo/odoo#93885
X-original-commit: 05f9f5db372b1a3644f85cb1de3c443b722ef309
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Now that it potentially contains guests, the previous name is no longer correct.
Part of task-2883466
closesodoo/odoo#93731
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
And use it on partner im status.
This will allow displaying the im status of guest without any other change to
components.
Part of task-2883466
Part-of: odoo/odoo#93731
* = im_livechat, test_discuss_full
Various improvements to user settings, including:
+ Introduce new js models `res.users.settings` and `res.users.settings.volumes`
to mirror the python models.
+ Avoid reformatting server data and simplify the way notifications are handled.
+ Clean dead code (unused convertData).
+ Reword and add documentation.
closesodoo/odoo#93390
Related: odoo/enterprise#28291
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Commodity now uses product county of origin code instead of
country of origin field directly since its a res.country model
and breaks the request if set on a product
closesodoo/odoo#93195
X-original-commit: 980d103050fee552a9f68421cf119c119397bbe2
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Currently, 'sale_crm' depends on 'sale_management' and not on 'sale'.
However, it does not include the features linked with the real 'Sales'
app(sale_management). Just the 'sale' core is enough.
Apart from that, when 'sale_renting_crm' is installed, we want to
separate the regular quotations / orders linked leads from the
rental ones. Now, 'sale_renting_crm' depends on 'sale' only, and
can be installed independently of 'sale_crm' which makes it difficult
to separate the rental and regular quotations / orders.
To correct behavior (split the rental and regular orders), we now make
'sale_crm' dependent on basic 'sale' instead of 'sale_management'. And
in the enterprise PR, we make 'sale_renting_crm' dependent on 'sale_crm'.
Also, to ease the splitting, this commit introduces two methods that
returns domains to filter out sale orders/quotations, which can be
overridden when needed (mainly from 'sale_renting_crm' to exclude rental
orders).
taskID-2627580
closesodoo/odoo#83030
Related: odoo/enterprise#20708
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The session value is updated each time the user modifies the wishlist.
The number is also updated when the user go on the wishlist page or if
the value is different from that of the HTML content (if the user does
undo in his history).
opw-2737985
closesodoo/odoo#92962
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
The session value is updated each time the user modifies the cart.
The number is also updated when the user hovers the mouse over the cart,
and if the value is different from that of the HTML content (if the user
does undo in his history).
opw-2737985
Part-of: odoo/odoo#92962
Add a new module that makes three new fields available on the invoices.
These fields are required when using facturx to send invoices to
public services through Chorus PRO.
The original template is updated to make it easier when integrating
the ubl refactoring coming soon, and avoid template issues that would
happen with an inherit if the inheriting module isn't updated after the
refactoring deployment.
opw-2714544
closesodoo/odoo#93877
X-original-commit: 4978d90cda34fd6c0b21bacb8462e1b9d4fb1241
Signed-off-by: Laurent Smet <las@odoo.com>
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>
Iryna Vyshnevska