Before this commit, the "style-inline" option was misspelled as
"styleInline", resulting in setting the Wysiwyg "inlineStyle" option as
undefined. This broke functionality that depended on such option, such
as disabling the convertion of pasted/dropped base64-encoded images to
attachment for mail compose.
OPW-3448851
closesodoo/odoo#133406
X-original-commit: 4ec687366eca1e05716fe93dad77eef5a9981153
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Rodolpho Cammarosano de Lima (rcdl) <rcdl@odoo.com>
Needed a new view just to be able to change the default display text in the calendar
Task-3251698
closesodoo/odoo#126358
Related: odoo/enterprise#41304
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
- For the Planning app calendar we now need to be able to fetch specific fields from the filters record
we don't want to inherit the whole loadDynamicFilterSection method so we created an addFilterFields method
used to fetch specific fields from the record accroding to the filterInfo ()
- we also need to display specific text when creating a new record from the calendar view, for exemple in calendar 'New Shift'
rather than 'New event' but we don't need to override the whole editRecord() method so we created a getter: editRecordDefaultDisplayText()
- For the css files, we lowered a bit the checkmark icon in the filters, and we added a new class that prevents the icons background
to become invisible when the filter checkmark isn't changed
Task-3251698
Part-of: odoo/odoo#126358
Purpose
=======
Allow to drag and drop properties to re-arrange them. Also allow to drag
and drop an entire group of properties by drag and dropping the
separator of the group.
Specification
=============
If we have no groups, and we move properties, we want to create
automatically new groups in order to keep the column separation.
So if we have
```
AC
BD
```
and you move B in the second column, we will create 2 groups to keep
the separation, so it will become
```
12
--
AC
D
B
```
so `C` stay in the second column.
Task-3188915
closesodoo/odoo#113974
Related: odoo/enterprise#37668
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Add the "separator" properties type, to be able to group properties.
Specification
=============
The separator creates a group until the next separator, we can fold and
unfold the properties in a group.
Technical
=========
The separator is only stored on the definition record, so it does not
take more space than needed.
The "fold" information is stored in the local storage, and is therefore
per user, but shared for all records of the same parent.
We use a properties type for it, to be able to use the exact same code
as other properties (so we can easily move the separator, etc). So
the order of the properties in the definition, and the position of the
separators will create the groups.
Task-3188915
Part-of: odoo/odoo#113974
Since [1] the line height is specified as an absolute height instead of
a ratio of the font size. This leads to multiline text with big font
sizes to overlap.
This commit removes the `rem` unit from the `body-line-height` primary
SCSS variable.
Steps to reproduce:
- Drop a text snippet.
- Select a paragraph.
- Change font size to 62.
=> Lines of paragraph did overlap.
In case the value had been edited before this fix, it will be shown
with the "rem" text within the option, which can be removed to update
the value to the correct behavior.
[1]: https://github.com/odoo/odoo/commit/388e4bb2bfcaebdd4ff30277fb49a034592d7086
task-3471117
closesodoo/odoo#133401
X-original-commit: a368dad33d128c95262053769e3f5de852d2be3a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
This commit fixes an issue introduced in #118966. For the mobile preview
feature of email marketing, styles used to be loaded by rendering an "empty"
template with the necessary styles. These styles, however, are no longer
imported in a template, but instead in mass_mailing's manifest.
The fix is to manually load the bundle and create the link tags to add the style
to the mobile phone preview.
Task-3465776
closesodoo/odoo#133400
X-original-commit: b2796d8016be83a1d08f28ef48e98db90c07da69
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
After this commit, we prevent the slideshow from appearing when clicking
on an "Images Wall" snippet image that has been set as a link.
Steps to reproduce the bug:
- Drag and drop an "Images Wall" snippet onto the page.
- Add some images in the snippet.
- Click on an image within the snippet.
- In the editor text toolbar, click on the "Link" button.
- Set the URL of the link to "/contactus".
- Click on the "Save" button in the modal.
- Save the page.
- Click on the image with the link.
- Bug: The slideshow briefly appears before redirecting to the "contact
us" page.
task-3425624
closesodoo/odoo#133396
X-original-commit: 8b29eabbd5a01ab225c93f519ea39724bdf3c0b9
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
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>
Rodolpho Lima