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>
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
Damien Bouvy