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>
If a list of emails is bigger than 500, the email was sent several
time to some people.
The mail_values content was not reset between each batch, so if 1200
emails are sent, 3 mail.mail records were created for the emails in
the first group.
closesodoo/odoo#93658
X-original-commit: f838a0cc36e51e0f47daeec6522df8e9832aad2c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, the DateTime range for getting events was six years,
while the Microsoft range limit is five years.
opw-2819858
closesodoo/odoo#93657
X-original-commit: 56f9b7646269d953c3068a12f20436d3afc970b1
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
When you are in anglo saxon accounting with posting stock changes at the
end of the session, we get an issue by using the refund feature in
backend.
If you have an order invoiced, and want to refund it, it'll create the
picking of the order immediately, which is not normal as it should only
be done when there is an invoice.
The problem is that the value of the field 'to_invoice' from the
original order is copied to the refund, and so act as the invoice is
made for the return.
To avoid this behavior, we are avoiding to copy it.
OPW-2848356
closesodoo/odoo#93645
X-original-commit: e8ef74397c0b02d051823142c3457413aabfeb21
Signed-off-by: Masereel Pierre <pim@odoo.com>
Steps to reproduce:
- Install puchases, accounting, contact
- Create a new company with a bank account
- Create a new person contact linked to the previous company
- Make a purchase order from that person
- Make a vendor bill using the auto-complete as the previous PO
Issue:
The bank account field is not filled
Cause:
The _prepare_invoice function tries to grab the bank information
from the contact on the PO. But in the case of a person of a company,
this information is stored in the parent company. Resulting in an empty
value
Solution:
Use the field "comercial_partner_id" to get the bank id. As this field
will use the parent company if the current partner is a person.
opw-2849706
closesodoo/odoo#93487
X-original-commit: c5f94e84dd5d6ec108484425d348053961bd13ff
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
This commit aims at unifying the UBL formats for invoices and credit notes.
Starting from the work of LAS, the module account_edi_ubl_cii contains the templates for UBL and CII,
and provides inheritance for UBL: UBL 2.0 < UBL 2.1 < UBL Bis 3.
It contains also the formats E-FFF, EHF3 (fully covered by Bis 3), NLCIUS, XRechnung (in UBL), Factur-x (the only one in CII).
All these formats are also improved to pass the ecosio validator and/or the country specific validator
(for Factur-x: the validator from the FNFE, and Chorus Pro).
Note that the xml files generated contain the pdf of the invoice/credit note encoded in base64.
An xml file alone imported in Odoo will thus automatically retrieve the pdf.
Before generating the xml files, we now also check a series of known constraints and possibly display
a warning on top of the move view if some are not enforced (the xml file is generated anyway but it might not be valid).
Tests were required: a new module was needed with dependency to the tested l10n: l10n_account_edi_ubl_cii_tests.
The prefix "l10n_" prevents runbot from launching the tests everytime.
The following modules are removed:
* account_edi_facturx
* account_edi_ubl
* account_edi_ubl_bis3
* l10n_no_edi
* l10n_nl_edi
* l10n_be_edi
Task: 2628093
See also: odoo/upgrade#3581closesodoo/odoo#93135
Signed-off-by: Laurent Smet <las@odoo.com>
Currently, when creating a new stage, even if there are sales team(s)
available, the `team_count` always displays zero, because it is a
computed field but is not dependent on any other field.
This commit improves the behavior by small hack, which makes the
compute method dependent on `team_id` field so that it can be
triggered while creating a record.
taskID-2819559
closesodoo/odoo#88738
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, when creating a new user, even if there are multiple
companies to select from, the "Multi Companies" related fields are
not visible in the form view. However once the record is saved, they
simply appear. This happens because the `companies_count` field based
on which the visibility changes, is a computed one but is not dependent
on any other field, and so while creating a new record, the value is
always zero for our compute field.
This commit improves the behavior by making the compute method
dependent on `company_id` field so that it can be triggered while
creating the record (thanks to default value being set for this field),
and thus shows / hides the company related fields properly.
taskID-2819559
Part-of: odoo/odoo#88738
When create a sale order from a opportunity the default value
for the team_id was wrong and thus the team_id was not properly set
Solution
--------
Return the id of the team not a tuple that contains the id of the team
closesodoo/odoo#93631
X-original-commit: 9c172745dcb9aa755079e2b63a7e9e69442b867f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Nemael