In a kanban (or list actually) view grouped by a many2one field,
the "false" group is folded by default. Before this commit, if the
user opened it and then reloaded the view (e.g. by applying a
filter in the search view), the group was folded again. With this
commit, the group remains open if the user manually opened it.
closesodoo/odoo#133305
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Before this commit, when a list view was grouped by more than 1
field, the view was considered empty, and the no content helper
was displayed. For instance, go to Contacts and group by Company
and Country.
Part-of: odoo/odoo#133305
Description of the issue/feature this PR addresses:
In the sales module, when creating a new product, it is important to ensure that
the product type is set to Service and that the invoicing policy is based on
milestones. Additionally, selecting the project field is necessary to ensure
that the product is linked to a specific project. Once the product is linked
to a project, it is important to make sure that there is at least one milestone
available within the project.
Once the above steps are completed, creating a sales order (SO) and adding the
newly created product will allow for the milestone stat button to be available
in the draft state.
Current behavior before PR:
The inclusion of the milestone product triggers the visibility of the stat
button.
Desired behavior after PR is merged:
If the state is draft, the milestone stat button ought not to be visible.
Fix:
Adding a condition prevents the stat button from being displayed when the
the current state is draft
task-3374861
closesodoo/odoo#133025
X-original-commit: 2b046e2c6c1e473f71c638c17c588b5b7fed7173
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
A check was added to prevent importing records with prefixes of existing
modules: https://github.com/odoo/odoo/pull/130825 . This queries the
known modules, but non-admin users don't have access to that by default,
causing the import to fail for them. Allow the module query regardless
of access rights.
closesodoo/odoo#133405
X-original-commit: e1dcf886129f47fdc121f121df15a2c4724bb0e2
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Merel Geens <mege@odoo.com>
The account tour was failing in case some entries were hashed or
were linked to deferral entries because these kind of entries cannot
be deleted but only reverted.
task-id 3437130
closesodoo/odoo#133330
X-original-commit: 4a3ce2701179c481e7506ccbde06663759f03e53
Related: odoo/enterprise#46404
Signed-off-by: Ricardo Gomes Rodrigues (rigr) <rigr@odoo.com>
Since commit cf844e34, we have a new group `group_sanitize_override`
that allow to prevent users from adding code that will be evaluated.
To know if a user can edit a field if they are restricted editor and
without this group, we do the diff between the normalized version and
the sanitized.
It is difficult to debug in production why a user cannot edit a html
field because we don't have the log of this diff.
Now we add the unified diff into the log. It should not occur too often
and if necessary we will reduce the occurrences in the log later.
(if debug mode, if loaded into the iframe [in edit mode with @], ...)
closesodoo/odoo#133395
X-original-commit: d60759d637a85d2220cee7566483bf3cff93b810
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Scenario:
- edit the current document layout and use is_html_empty method in it
- it works in Preview Document, when printing any report, ...
=> it breaks when opening document layout wizard by clicking on
"Configure Document Layout"
Reason: is_html_empty was added to _get_rendering_context, but the
preview instead the document layout wizard doesn't use this method.
Fix: add is_html_empty in the context
opw-3433583
closesodoo/odoo#133122
X-original-commit: 5f1ad0c1e4c1e8ed41337ccd4c12e70c9c760c85
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In this commit, I have made the changes to align the IRN no.
and its related QR code image properly in the invoice
report. before this commit,it overlapped with the tax details.
Steps To Reproduce:
- Install the `l10n_in_edi`
- Switch to `IN Company`
- Go to Configuration->Journals
- Under the `Advance Settings` tab, tick the `Electronic Invoicing`.
- Create an invoice
- Click on `process now` to process an e-invoice.
- Now, print the invoice report.
- You will find the E-invoice code overlaps with the Tax Details.
task:- 3347517
closesodoo/odoo#133007
X-original-commit: 0693552dbb6cf4d160c88da90b8b08d28213d9b6
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Main
-
[IMP] stock_account: Allow to keep track of the COGS Journal Items origin
Explain
-
So far It is quite cumbersome to try to figure out which lines are
coming from where for the COGS journal items. It becomes more difficult
to find them out when there are several lines from the same product with
the same quantities and similar characteristics.
By having what invoice line originated which COGS Journal Items you can
auditing and analysis in a more thorough way.
- You can figure out which Sale Line o Invoice Line was more profitable.
Based on the actual revenue and the actual COGS.
- What COGS line was mistakenly created. For instance, when the invoice
is created prior delivery, you can figure out how to surgically fix
the of COGS journal items that that were wrong.
- To try to reconcile properly the lines in a Sale Order Line when there
is drift and reconciliation is not properly made because there were
differences and they cannot be easily spotted because you get lost in
middle of several COGS lines but you do not know where they are really
coming from.
closesodoo/odoo#125134
Signed-off-by: William André (wan) <wan@odoo.com>
In this commit, we have implemented the functionality to show the color
of the project in the left side panel of the calendar and calendar entries.
task-3251766
closesodoo/odoo#130700
Related: odoo/enterprise#41569
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Issue:
Two services which difference is that one is expensable with an
expense policy different of none, the expensable service is not
included in the project profitability as revenue from a service,
even it's not actually an expense, just a service that "could be"
expensed. The other service which is not marked as "can be expensed"
is correctly computed in the project profitability.
Steps to reproduce:
- Install Project, Accounting, Sales, Expenses
- Settings > activate analytic accounting
- Create a service, invoiced on milestones, creates a project on SO
confirmation, can be expensed with an expense policy of Sales price.
- Create an SO, confirm the SO
- Set the milestone to 50% reached, invoice the SO, post it
- Go to the project profitability of the project, notice there is no
revenue section for the service.
- If you follow these same steps for a service which is not set "can
be expensed", the service is correctly included as revenue from
service billable milestone.
Cause:
When computing the profitability items from services, we first get
the `sale_line_ids` (whose domain excludes the expenses), then we get
the product that are linked to those sale_line_ids, but we exclude
products that have an expense_policy different than 'no'. This
domain may not be necessary, because `sale_line_ids` already exclude
expenses.
Fix:
Remove the particular domain leaf.
Affected versions:
16 up to master
Reference:
opw-3430020
closesodoo/odoo#133307
X-original-commit: ac02616c4d54120defa53e9ef463cdcbab69063b
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to reproduce:
-------------------
- create an event in the calendar;
- click on "Everybody's calendars" filter;
- delete the event.
Issue:
------
The event name is crossed out (declined)
instead of being deleted,
even if we are the organizer.
Cause:
------
The value of `event.attendee_id` inside the
`_onDeleteRecord` is `undefined`.
The condition will therefore never be `true`.
Solution:
---------
Add the organizer's id to the event
so that he can delete it in the case
of "Everybody's calendars" filter.
Note:
-----
Correct decline event from calendar view.
opw-3230254
closesodoo/odoo#133298
X-original-commit: 4ef44f403f1c93b62230307f5fa909b8a83f4eb8
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Steps to reproduce
==================
- Login as a user with no rights
- Use a mobile viewport
- Create a new Maintenance Request
- Edit the Created By field
-> A traceback occurs because the user has no rights
Solution
========
We extend the Many2OneField to accept a relation option and Depending on
whether the user has the rights, use the correct one.
This is similar to 41eaff0f4c17
opw-3430105
closesodoo/odoo#133261
X-original-commit: e78998c2951ec906fbccbe24e3fa454711a37c2b
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Previous PR: odoo/odoo#113973 assumed that if stock_accounting_automatic
setting was disabled, then the user deactivated the setting and it was
previously on => we should change all of the property_valuations to
'manual_periodic'. Unfortunately this missed the case where the
property_valuations were set to `real_time` without the setting being
active (i.e. upgraded db and the setting isn't activated or the
value is set directly via ssh or community module)
Additionally, it was causing an unnecessary search on product.category
every time a setting is changed. Therefore we now only change the
`property_valuation` if the setting was active and was changed to not
active.
OPW-3474598 for context
closesodoo/odoo#133254
X-original-commit: 96b17f9a19855a78a7b879299ea51eb5bde0acf8
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
They existed solely for typedoc and wrapping `useState()`.
- Typedoc is managed by `useService()` and `services.d.ts`.
- `useState()` is a minimal code in component, and is actually
more useful as explicitly visible in component.
closesodoo/odoo#133202
Related: odoo/enterprise#46327
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
In preparation of code cleaning of models in store.
Entries in store are allocated per model, using the model name.
Records of a model can be accessed from `store[ModelName].records`.
Part-of: odoo/odoo#133202
Steps:
- Create a product tracked by serial number
- Create a new scrap order in inventory -> operations
- Add the created product, the serial number and save.
Issue:
The quantity is automatically set to 0.00 after saving.
Reason:
The ``StockScrap.scrap_qty`` field is computed and has a default value set to 0.0. On the
xml form view when ``StockScrap.tracking`` is set to 'serial' the field is readonly and is not
sent to the server when saving so the default value is used.
The problem appears because initially the ``StockScrap.scrap_qty`` was precomputed so even it wasn't
sent by the form, we already had the value. With the changes made we can't use ``precompute=True``
because ``StockScrap.scrap_qty`` depends on fields which aren't precomputed.
Solution:
In this context we have 3 cases:
- If ``StockScrap.tracking`` is 'none', ``scrap_qty`` is not readonly so sent.
- If ``StockScrap.tracking`` is 'lot', ``scrap_qty`` is not readonly so sent.
- If ``StockScrap.tracking`` is 'serial', ``scrap_qty`` is readonly so not sent.
As the only case of the issue is when the product is tracked by serial number(only one product) we can,
set the default value of ``StockScrap.scrap_qty`` to 1.
opw-3470888
closesodoo/odoo#132895
X-original-commit: 0d9fa534c3c17e87210f9d24cc90991d6dd8c0be
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Eteil Junior Djoumatchoua (etdj) <etdj@odoo.com>
Before this commit:
Remove Block tooltip gets stuck after click and mousemove.
After this commit:
Remove Block tooltip hides as mousemoves.
task-3432060
closesodoo/odoo#132888
X-original-commit: 095721a9cace476c3eae445c7abd8f8b458aea36
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
As it is not possible to have a `.o_wslides_home_nav` in a `o_quiz_main`
we can remove the scss dead code related to it.
task-3476128
closesodoo/odoo#132793
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Bug
===
Since 8723f020c3 , they are some tracebacks
with the properties when switching the views. For example, if you open
a many2many properties record (by clicking on the badge), and then go
back to the original form view, a traceback is raised.
Task-3460126
closesodoo/odoo#131394
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Bug
===
Since 7d2baaa0c7 , we read the field
with `web_read`. We don't load the display name when calling read,
but instead we load them after.
But, since this change, the display names of the relational
properties are not loaded.
To fix that, we always load the display name of the relational
properties because it's a purely frontend field.
Task-3460126
Part-of: odoo/odoo#131394
Before this commit:
When printing a receipt with an epson printers models TM-U2X0 (like
TM-U220), random characters will be printed instead of the receipt.
This happened as a picture of the receipt is sent to the IoT box, but
the TM-U2X0 models does not support all "Bit Image commands". We
currently use the GS v 0 one which is not supported by this printer
models. See:
https://reference.epson-biz.com/modules/ref_escpos/index.php?content_id=94
In addition, of that, the command itself is obsolete.
After this commit:
The support for another command "ESC *" is added which is not obsolete
and supported by TM-U2X0 models.
Notes:
- Compared to "GS v 0", the receipt printed with "ESC *" is worst:
- It take longer to print (5 seconds vs 1 second)
- There is consistently some thin "empty white lines"
- Most of the code is inspired from `python-escpos`:
https://github.com/python-escpos/python-escpos/blob/master/src/escpos/escpos.py
Due to the drawbacks, making it the default way to print would be a bad
idea. As such, we can configure the mode (with other parameters) using
particular name for the printer (which can be done by adding it manually
with cups)
opw-3351084,3341907
closesodoo/odoo#131332
X-original-commit: f30085bf673712c205e7ff318961d597297648d0
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Loan Sens (lse) <lse@odoo.com>
This error occurs when a user tries to add an Invalid attribute
(ex-help, searchable) to an element field.
Steps to produce:
- Install Studio.
- Open any tree view.
- Activate studio > Go to views > Click on XML.
- Add an attribute help inside any field.
So, this commit handles the case by changing the logger error to logger warning.
sentry-4377111502
closesodoo/odoo#131164
X-original-commit: 10f45eacdfd4c6fe5d86659276d145a563f60c6c
Signed-off-by: Fabien Pinckaers (fp) <fp@odoo.com>
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
before this commit, when time and material section is visible then 'To invoiced'
field is also visible in portal.
This commit hide the 'To invoiced' field in portal when time and material
section is visible and rename some fields.
closesodoo/odoo#126053
Task: 3251754
Related: odoo/enterprise#42995
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
With Python 3.11, PyPDF2 2.12.1 is used and the exception raised when
the encryption type is not supported is now `NotImplementedError`
instead of `PdfReadError` in previous version.
In order to support both version, this commit adds a catche for the
`NotImplementedError` too.
closesodoo/odoo#133242
X-original-commit: effff7e00d8d410106e12e7ea42c8a875a11bb8b
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
When creating a reconciliation model line on
a new record, by activate the boolean toggle on
`force_tax_included` field, the line is save
but as the reco model is not, `check_company`
will raise an error.
Steps:
- Create a new model
- Before saving, create a line, set a tax and
click on Tax included toggle button
-> Error is raised
opw-3473189
closesodoo/odoo#133233
X-original-commit: 796478445e5bc7da95b8a0aaab4dcbe235bb2957
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
In 89d5d1f, changes have been made to the catalog to ease inheritance.
Since this change, opening the catalog with products spread over
multiple lines on the SO crashes.
Now, the catalog will open even if the SO contains products spread
across multiple lines.
closesodoo/odoo#133217
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, when replying to a message from mailbox
in the Discuss app (e.g. Inbox or History) and then clicking
on the "Full Composer" button, there was the following crash:
```
Invalid res_ids ['history'] (type <class 'str'>)
```
This happens because the full composer button was attempting to open
the full composer on the mailbox at hand, e.g. 'history', instead of
the document related to the message, i.e. the origin thread of the
message.
The code of this button assumes that it's only visible when viewing
the message in the origin thread. In this case, the shown thread
(`props.composer.thread`) matches the origin thread (`thread`) of
message. This is always the case except in mailboxes, so using
`props.composer.thread` is erroneous in mailboxes.
This commit fixes the issue by correctly opening the full composer of
the document related to the message, by using `thread` instead of
`props.composer.thread`, which is the origin thread of the message.
Also make full composer button rounded (`mx-1` => `m-1`)
opw-3453680
closesodoo/odoo#132910
X-original-commit: 69d1776513a5eff06fca84bc070c4678b84829ed
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
It's possible to specify an existing module as the xml id prefix when
importing records from a file. This will result in `ir_module_data`
records being created with `noupdate` set to False. When the module is
upgraded, these records will be deleted.
This can lead to undesired side effects like journal items for
accounts imported this way being deleted.
This change prevents creating new records linked to existing modules
when importing from a file. Instead, the user should either use no
prefix or the name of a non-existent module, like `__import__`.
opw-3231987
closesodoo/odoo#133263
X-original-commit: 8f12d14c4c4354a63c94f14e7a89abc6048525f9
Signed-off-by: Merel Geens <mege@odoo.com>
Steps to reproduce:
-------------------
- create a job position without specifying the company;
- being in the first company, create an application for this job position;
- being in the second company, create an other application;
- go to the job position kanban view;
Issue:
------
Despite the selected company, the count for this job application is still two.
Solution:
---------
Include the allowed companies in the query to count the number of applicants.
opw-3453348
closesodoo/odoo#133262
X-original-commit: 8bce129a9943448e51a0e672a1ac18a3c1221866
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
In the project, the kanban view assign button is visible in the subtask
task-3374861
closesodoo/odoo#132986
X-original-commit: 2669881160e474459158e61e9914e3024ae75d5e
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Project Sharing subtasks view's notebook, hide the Billable field which is an
read-only field
task-3374861
X-original-commit: 2d932181d6c7d86b26a07d10990b453f7b86a938
Part-of: odoo/odoo#132986
If the user is using the `note` or any other module to add and modify images,
and they try to crop the image and apply the changes, they may face an error if
they try to crop it again without clicking on `apply changes` and instead click
somewhere outside the image.
steps to produce:
- Install `note`.
- Create a note, add an image in it.
- Click on image to crop it, select the portion you want to crop and then
click on `Apply` to apply changes.
- Select the image again, click on crop icon and then click anywhere outside the
image boundaries.
Error: `TypeError: 'bool' object is not subscriptable`.
Applying this commit will solve the issue because, after applying it, whenever
`modify_image` is called, `datas` will receive the proper source.
sentry-4185609374
closesodoo/odoo#133164
X-original-commit: 0c38bb37e720a3c06f59becbf9bcc78f9f978723
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Use the operator inselect instead of in with a read() before it.
This ensures a subquery is used instead of two separate queries.
When you have a user that is following thousands of tasks and the
security filter depends on this search, all queries are very slow. Using
a subquery prevents from reading these ids and sending back a very long
query to the database.
closesodoo/odoo#133273
X-original-commit: 7f9e98c0d7441b2103df0b89183b6949f3bc9b69
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps:
- Install project
- run project tour
Issue:
- no description while adding the column
Cause:
- the description was not present in the project tour for column
Fix:
- added description for adding a column in the tour
task-3388985
closesodoo/odoo#133047
X-original-commit: a3f12bcebf66e57212ce0e6d4b46f986ae6c9c33
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
steps:
-install sale module.
-create product with product type as course
-Generate a sale order containing the newly created product.
-link the sale order to any project task, and then attempt to view the tasks
stat button by clicking. However, encounter an unexpected traceback or error
message during this action.
issue:
In the sale module quotation view, the traceback is occurring when clicking on
the tasks stat button
fix:
Improved action_view_task method in sale_order model to handle missing sales
order lines with 'service' products. Set default project ID when no suitable
sales order line is found, preventing errors and ensuring smooth functionality.
Refactor involved using conditional expressions for better readability and
maintaining default behavior.
task-3436556
closesodoo/odoo#132981
X-original-commit: 10838145c0981e46221b2cbf65b2c4ce84c3b8c7
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit quantity_percentage field was not editable in list view
Issue:
- when trying to edit quantity field in milestone , it's not editable in list view
Fix
- when trying to edit quantity field in milestone it becomes editable by making
field readonly false
task-3444728
closesodoo/odoo#132958
X-original-commit: 562a454731326a054f8f4c54e8350a2faf1c1c7f
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Connecting a cashdrawer to an ePoS printer in direct device ( NOT with
an IoT box) will not automatically open the cashdrawer as it would be
intended when paying with cash.
This happens due to the fact that we check that the printer connection
is "connected" which is not the case with direct device as it use the
default value in the setup which is "disconnected".
opw-3470241
closesodoo/odoo#133216
X-original-commit: 339a76885db0f2034bae21eec76d0127d2733205
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Loan Sens (lse) <lse@odoo.com>
When adding a bank account via the setup wizard,
an User Error is raised ("Incompatible companies on records")
Since 0479b2b594,
`check_company` is set to `True` on
`SetupBarBankConfigWizard.linked_journal_id`, but
the model has no `company_id` field.
Therefore in `BaseModel._check_company()`, no
company is found and we raise the error.
Steps:
- Go to accounting dashboard
- Make sure the "onboarding" banner is not removed from the view
- Click on "Add a bank account" on the banner
- Try to create a new one (bottom right of the wizard)
- Enter an account number, select a bank and validate
-> Error is raised
opw-3473184
closesodoo/odoo#133214
X-original-commit: 8d9c0c27d389ecd21a5c32ebba1e8da14316b6c0
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
When opening the list view of workorders, a traceback was triggered.
The problem was that parent was not defined when not in a view form.
Checking if parent first exists solves the problem
closesodoo/odoo#133213
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The Mail Debug tab is confusing for users and should only be used by
people who know what can or cannot be expected from it. It is not
providing a good preview of the e-mail's rendering since the HTML it
displays is not meant to be rendered by a browser but by all sorts of
e-mail clients. This means that some things that render properly in it
won't necessarily render properly in some e-mail clients, but also
likewise that some things that don't render properly in it will in fact
render as expected in e-mail clients. This is why it's only available in
debug mode but since many users routinely enable debug mode to get
access to hidden features, this is not enough to prevent them from
reporting issues that are not issues.
closesodoo/odoo#133208
X-original-commit: 240ee9deb898f4346a9bc66548c881fc69e8b117
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Aaron Bohy