Prior to this commit, fiscal positions auto-detecion was completely override for Argentinian countries.
With this improvements the afip responsibility field can be combined as a filter to choose the proper fiscal position.
Example of a new use case could be:
* Name: Gross Income Perceptions Buenos Aires
* Detect Automatically = True
* Afip Resp. Type = Responsable Inscripto
* Country = Argentina
* Federal states = Buenos Aires
So, this fiscal position will be automatically choosen only for responsables inscriptos of Buenos Aires.
Previous use cases still work.
closesodoo/odoo#150652
X-original-commit: 4c5987eb1ac7687eb0c6467d99fb3052e4843a07
Signed-off-by: Josse Colpaert <jco@odoo.com>
When we update an inline translated element (like `<span>`) for the base
language `en_US` we should update the modifiers attributes for all
languages.
For example when updating from (16.0)
https://github.com/odoo/odoo/blob/7ecd9413/odoo/addons/base/views/ir_ui_view_views.xml#L127-L129https://github.com/odoo/odoo/blob/7ecd9413/odoo/addons/base/i18n/fr.po#L7233-L7235
to (17.0)
https://github.com/odoo/odoo/blob/b1461d28/odoo/addons/base/views/ir_ui_view_views.xml#L126-L128https://github.com/odoo/odoo/blob/b1461d28/odoo/addons/base/i18n/fr.po#L12087-L12089
The base term, `en_US`, is updated since the text matches but the
attributes of the translated terms, `fr_FR` for example, are not
updated. Later when the PO file is loaded in non-overwrite mode the
translated terms for `fr_FR` is not updated. This causes all sort of
issues during an upgrade for inline-translated terms -- like `<span>`.
More so since the recent change that converts domain-based attributes
into inline Python expressions.
In this patch we propagate modifiers attributes from inline-translated
items in the new base term into all translated terms when the base term
is updated. In that way we ensure the attributes are correct in all
languages even if later the loading of their corresponding PO file
doesn't update the term.
For a detailed example, let's see what happens when loading the view
above during an upgrade 16->17, right at the first load of the XML file
at https://github.com/odoo/odoo/blob/b1461d28/odoo/fields.py#L1864
```
(Pdb) p old_term
'<span attrs="{\'invisible\': [(\'reset_mode\', \'!=\', \'soft\')]}">This view has no previous version.</span>\n <span attrs="{\'invisible\': [(\'reset_mode\', \'!=\', \'hard\')]}">This view is not coming from a file.</span>\n <span attrs="{\'invisible\': [(\'reset_mode\', \'!=\', \'other_view\')]}">You need two views to compare.</span>'
(Pdb) p closest_term
'<span invisible="reset_mode != \'soft\'">This view has no previous version.</span>\n <span invisible="reset_mode != \'hard\'">This view is not coming from a file.</span>\n <span invisible="reset_mode != \'other_view\'">You need two views to compare.</span>'
(Pdb) p translation_dictionary[old_term]
defaultdict(<class 'dict'>, {'fr_FR': '<span attrs="{\'invisible\': [(\'reset_mode\', \'!=\', \'soft\')]}">Cette vue n\'a pas de version antérieure.</span>\n <span attrs="{\'invisible\': [(\'reset_mode\', \'!=\', \'hard\')]}">Cette vue ne provient pas d\'un fichier.</span>\n <span attrs="{\'invisible\': [(\'reset_mode\', \'!=\', \'other_view\')]}">Vous avez besoin de deux vues pour comparer.</span>'})
```
As we can see the new term will get an updated value for its `invisible`
attribute, while also removing `attrs`. The translated terms will be
still keep the old modifier though.
Now later when the fr_FR.po file is loaded we reach this point
https://github.com/odoo/odoo/blob/b1461d28/odoo/tools/translate.py#L1442
```
(Pdb) p term_en
'<span invisible="reset_mode != \'soft\'">This view has no previous version.</span>\n <span invisible="reset_mode != \'hard\'">This view is not coming from a file.</span>\n <span invisible="reset_mode != \'other_view\'">You need two views to compare.</span>'
(Pdb) p translation_dictionary[term_en]
defaultdict(<function DeepDefaultDict at 0x7fc9640cdfc0>, {'fr_FR': '<span attrs="{\'invisible\': [(\'reset_mode\', \'!=\', \'soft\')]}">Cette vue n\'a pas de version antérieure.</span>\n <span attrs="{\'invisible\': [(\'reset_mode\', \'!=\', \'hard\')]}">Cette vue ne provient pas d\'un fichier.</span>\n <span attrs="{\'invisible\': [(\'reset_mode\', \'!=\', \'other_view\')]}">Vous avez besoin de deux vues pour comparer.</span>'})
```
Thus the translated values are NOT updated, keeping the _wrong_
modifiers. This is later fixed during the upgrade in a clumsy way.
C.f. the warnings like this one in runbot:
```
Incomplete conversion for view(id=77, lang=fr_FR) at
<span attrs="{'invisible': [('reset_mode', '!=', 'soft')]}">Cette vue n'a pas de version antérieure.</span>
```
Note that such warnings are gone in current PR CI.
The root issue here is that when the fr_FR translation is loaded the
terms are not updated due to a combination of factors:
1. The text content of the term didn't change
2. There is no override flag set for translations
Option 2 is not a valid option during upgrades because we want to keep
custom translations. We could instead of the current patch tweak how
option 1 works and perhaps make the closest term more restricted. This
would lead to the update of the whole translation though while the
actual issue here is _just_ the modifiers. Moreover if the translations
are out of sync the translated terms will still keep the wrong values
that could still be essential for the correct functioning of the record
they belong too (view archs -- for example).
Finally this is a more extreme case (16.0):
https://github.com/odoo/enterprise/blob/1e63b4a8/sale_subscription/views/sale_order_views.xml#L142
In this case during the upgrade we fix the modifier value (refer to
runbot warning above -- it's the same script that fixes it) and set
```
invisible="(subscription_management == 'upsell') or (recurrence_id == False)"
```
for translations, which is wrong. The correct value is (17.0):
```
invisible="not plan_id or subscription_state == '7_upsell'"
```
https://github.com/odoo/enterprise/blob/530ba3ad/sale_subscription/views/sale_order_views.xml#L136closesodoo/odoo#150152
Signed-off-by: Raphael Collet <rco@odoo.com>
`get_text_content` will transform contiguous space chars into single
spaces, plus translate special HTML elements
```
>>> " ".join(html.fromstring(f"a\n b & c").text_content().split())
'a b & c'
```
In order the correctly verify if a term is text-only we need to use the
HTML parser. Note that to be resilient against bad XML, but valid HTML,
we cannot use the default XML parser.
Part-of: odoo/odoo#150152
**Current behavior:**
Creating an additional company then creating an attendance
kiosk link for it will not display this company's logo.
---
**Expected behavior:**
The kiosk page displays the logo for whichever company is
actively selected when the link is generated
---
**Steps to reproduce:**
1. Create a second company, set the logo to anything besides
the default/fallback image
2. In the HR Attendance application settings, generate a kiosk
link then paste & go in an incognito window
3. Observe the logo image displayed above the bar code is the
default/fallback image
---
**Cause of the issue:**
The route being used to get the company's logo does not work
for companies which are not the first/default one generated
with the database. An accessibility check fails due to some
information about the user's access rights not being available
with the request.
---
**Fix:**
Use an alternative route which can properly access the logo
image file of the company that is active when the kiosk link is
generated.
---
opw-3672577
closesodoo/odoo#150628
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Currently the "Invoices to validate" link is broken in case the module
account_3way_match (from enterprise) is installed.
The same link / context is used for "Invoices to validate"
and "Bills to validate". (The text inside the link is just changed
depending on the journal type.)
The module account_3way_match changes the context of that link to
change the behaviour for the "Bills to validate" (bill specific filter).
This breaks the link for "Invoices to validate".
This commit makes invoices and bills have dedicated / separate links.
Thus after this commit account_3way_match only changes the behaviour of the "Bills to
validate" link.
task-3680398
closesodoo/odoo#149352
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Step to reproduce:
- Open a pos session
- Turn off the connection between the server and your POS instance
- Create an order offline
- Turn back on the connection between the server and your POS instance
- Close the POS session
Issue:
The order created offline is not synced to the server
Cause:
The sync of the order has been implemented for the button to go back to
the backend without closing but not for the closing session button.
Solution:
Make the synch mechanism common to both buttons.
closesodoo/odoo#151016
X-original-commit: 4d57ce4c740d6a3350318b4dbcd49c9f2f0f104c
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit:
- On table when we hit tab it displays toolbar as it sets selection between
startPosition and endPosition.
- On hitting tab it selects the text in the next cell completely, which
should not happen.
After this commit:
- Now toolbar is not displayed on hitting tab.
- selectionis made to collapse at the end the lastNode of the cell.
task-3475079
closesodoo/odoo#151653
X-original-commit: 9361133a24146528846cd2d69119c3e9045eafba
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit
==================
It was not allowed to cancel the invoice, an error message
was displayed, response as False was returned as it was always moving inside
else condition
After this commit
=================
After changes the error message has been removed and response
as True is returned, and allowed to cancel the invoice
task-3258582
closesodoo/odoo#151652
X-original-commit: 5a8826ec970dd87b203fdbc2214ac8381393ae2b
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Surabhi Varma (suva) <suva@odoo.com>
Without this patch, running this command on an environment where the tour will fail, will create massive and useless logs:
odoo --stop-after-init -i auth_totp --test-enable --test-tags /auth_totp
This is because this method is a callback that can come in a different thread, creating a race condition.
There's no problem on checking wether the directory exists before creating the file, and then safeguarding from the problem.
@moduon MT-1075
closesodoo/odoo#151579
X-original-commit: 7aca8ae8728c66700c3afdca350e99ea78a63d88
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This commit was written for Odoo 16.4 and then backported.
In Odoo 16, only point 2. described just below is not working.
The 16.4 commit was thus retarget to Odoo 16 as it was also fixing the
second point.
------------------
Before this commit:
The website selected in the website selector of the search view in the
website.page list/kanban view was always set to the first one found in
the DB and was never:
1. the one you visited in the website preview
2. or the one matching the URL of your backend.
But 1. was working fine before commit [1] from the frameworkjs which
introduced a way to "reset" the screen between apps/menu switch.
Despite 1. working before commit [1], it was not ideally coded and
worked "by chance", see below for a few facts and explication.
------------------
Fact 1:
When you have multiple websites and you are on a website, the website
served is the result of 2 possibilities:
1. All websites have a specific domain, then you can only see a given
website on its own domain. Attempting to select another website in
the website switcher will redirect you to that other website domain.
2. You have one or more websites without any domain, then you can see
those ones from any domain by using the website switcher. It will
force the website in session, and despite being on a domain which
should serve a given website (the one which has its domain set that
domain if there is one), it will serve you the one you selected in
the website switcher.
Fact 2:
- It is the `website_preview` which is setting the currentWebsite
property of the `website_service`.
- But the `website_service` can be used on its own, without any
`website_preview` being involved in the process.
- When the website preview is unmounted, the currentWebsite from the
website service is reset to null.
- The website page list component is reading the currentWebsite from the
website service.
- When switching from the website preview to another menu like the
website pages list, the page list component (PageControllerMixin) is
actually initialized/created before the website preview is unmounted.
In the end, the following happen:
1. Go to website preview -> it sets the website service current
website
2. Go to website page list
3. The website page list component reads the current website from the
website service which is set
4. The website preview is unmounted, emptying the current website from
the website service
5. The website page list is shown to the user
6. Any call from the page list component to the current website will
now be "wrong" / not return the same as during its `onWillStart`,
as website preview was unmounted just after that, emptying the
website set in the website service. Luckily, there is none.
Fact 3:
Commit [1] changed the order of the steps listed above, now 4 occurs
before 3, so when the page list component reads the website from the
website service, the unmount of the website preview already kicked in,
emptying that website service website.
This is the source of the bug fixed here: the current website could
never be found anymore.
-----------------
This commit is simply finding the current website_id by asking it to the
server.
It will fix point 1. listed at the very beginning of the commit message,
but will also make point 2. work.
Another solution would have been to find a workaround to the frameworkjs
change (like investigating the `noEmptyTransition` option) to restore
what we had before, but it would have been as "fragile" as before and
wouldn't have fixed other flows as the current fix does.
----------------
Steps to reproduce 1:
- Without any domain set, go to your DB in the website preview of your
website in the backend
- Switch to the website 2 in the navbar website switcher
- You are now viewing website 2 in the website preview
- Click on "Pages" in the "Site" menu to go to the page list view
- The website selected in the search view is the first one, not the
website 2. Also, the page shown are from the website 1, not the
website 2.
- This was working before commit [1] and this commit is fixing that.
But this commit is also fixing/improving flows which never worked:
- Before commit [1] (or in Odoo 16 to be simpler), do the same 4 first
steps as above.
- You will see that the listed pages are the ones from website 2 and
that the selected website is the second one, correct.
- Now just reload the page, it will show website 1, despite the website
2 being forced (if you did reload the page on the preview, it would
still show website 2).
- This is because the website_preview was never involved after the
reload since you reached the list view / website service without going
through the website preview.
- The same can be seen if you go to the Pages list view directly through
CTRL+K, in which case you won't go through the preview.
--------------------
Note that the chance is taken to reorder the wutils export, it was
becoming a real mess and it was not possible to easily read through the
method names to find/guess something.
------------------
[1]: https://github.com/odoo/odoo/commit/9f6ed9f6d1ef7ec1870980498480cae0ffc729d8
Related to task-3676124
opw-3658648
closesodoo/odoo#151269
X-original-commit: 0128beed551395b30f957a5edc1a23a6f3d0ba31
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In iot, when we send a request to
the route '/hw_posbox_homepage/password' we pass a variable which is unused.
And which therefore causes a warning in the iot logs.
This commit removes the query parameter.
closesodoo/odoo#151604
X-original-commit: f713d48f6393e58cf9c4b5fe08e1407ea2be8513
Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
`getLoggedInAsText` is a function, due to missing brackets
the function content was dumped instead of evaluation of function.
opw-3701333
closesodoo/odoo#151600
X-original-commit: 4ce21a4207a9dd7047a6b5ec9c447f9e48ca199c
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
The `see records` action that drill downs to the specific AccountMoveLines
that match the formula domain would break if we left some optional
formula arguments empty (specifically concerns the offset and companyId
arguments). This revision ensures that we use their default value when the
arguments are not provided.
closesodoo/odoo#151423
Task: 3621110
X-original-commit: 23bbb0cdebc9028fcc93e006e755c43000428fcb
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Steps to reproduce the problem:
- Add a "Countdown" snippet on the website.
- Save.
- Enter in edit mode again.
-> Problem: the `destroy()` of the `CountdownWidget` public widget comes
from a `widgets_start_request` that is triggered when the
`WysiwygAdapterComponent` has been mounted and patched (see
[useEffect documentation]). The problem is that, as the widgets are only
destroyed at this moment, it is possible that a widget could replace an
element that has been modified during the instantiation of the
`WysiwygAdapterComponent`. For example:
- At the `onWillStart()` hook of the `WysiwygAdapterComponent`, the
`o_editable` is added on some elements.
- A widget could then replace one of these elements.
- The widget is destroyed after the rendering of the
`WysiwygAdapterComponent`.
-> The `o_editable` class is not on the element anymore.
The goal of this commit is to, as before [1], destroy the existing
widgets before instantiating the `wysiwyg`.
This commit also adds a test to ensure that the order of the calls to
the widgets and wysiwyg lifecycle methods is coherent.
Related to runbot-28700
[1]: https://github.com/odoo/odoo/commit/a3e34512bf229d5d55f9e9d9eb0a9f7211a5a826
[useEffect documentation]: https://github.com/odoo/owl/blob/master/doc/reference/hooks.md#useeffectclosesodoo/odoo#151411
X-original-commit: 723c0dfeb7d39ca2522e65cf021664aacfc7099c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Fix 1:
Before this commit, the smart button on the employee would
display `x/y` Time Off, indicating remaining leaves over max leaves.
However, while `y` was correctly taking into account current
allocations only, `x` didn't, resulting in incoherent values.
Reproduce the issue:
- For an employee, create an expired allocation and validate it of x days;
- Create an additional allocation which is still valid today of y days
and validate it as well;
- Go on the employee form view;
- Time Off smart button display (x+y)/y instead of y/y
Fix 2:
Before this commit, there was no way to track error inducing leaves
that were created through a bug or that were already created in the
database prior to the changes brought in version 17.0.
This commit adds a new property in the leave data indicating the id
and the start date of the leave that is causing the discrepancies
in the database and displays a warning on the dashboard if
there are some error inducing leaves.
closesodoo/odoo#151288
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Since the refactoring of base_automation, the 'website-publishing'
option of server actions was broken; it did get included in the view
but outside of a group node and without labels. The result was a
floating checkbox which would trigger a label-less char field upon
selection - not the clearest of UIs.
This commit properly insert these fields into a group node. Note that
since server actions can normally only be reached by going through
technical menus, the fact that this section of view is now in a
group_no_one-only section should not change anything functionally.
closesodoo/odoo#151498
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Prior to this commit, when adding a product to an order, navigating
back to the floor screen, and subsequently reopening the table,
clicking on "Order" would send the order to the preparation display
again. The issue stemmed from the fact that "this" was being added to
"ordersToUpdateSet" in posStore, whereas "order" should be added to
that set.
opw-3687977
closesodoo/odoo#150973
X-original-commit: 633179542d8cd7e32c51f4d6bd9c25decb2e56ae
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Before this commit, the date was being considered in UTC instead of the time zone of the current user. This is problematic in LATAM, where the time zone is negative.
closesodoo/odoo#150956
X-original-commit: 95acd53827ed128b301800dbabd5a8d9d7cbd12c
Signed-off-by: John Laterre (jol) <jol@odoo.com>
When creating a picking on mobile, the moves are displayed as kanban
boxes. But before this commit, only the mvoe's `quantity` is displayed,
that means when in draft, the quantity is usually at 0 and it's the
demand (`product_uom_qty`) who is relevant.
To fix that, display both fields.
Also, we display the UoM aswell if the UoM is enabled.
closesodoo/odoo#144282
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The `stock.move` form view used for the detailed operation is also used
when using Odoo on a mobile device and is not usable in such case (for
example, the `product_id` is readonly.)
To fix this issue, the view is modified this way:
- The `product_id` is readonly only if the move has a id or already a
move line (that way, the field is editable when creating a new move
but is still readonly otherwise);
- The `move_line_ids` is readonly until the move's product is set;
- The demand qty. and the UoM are editable if the move is draft.
Also, some similar mofifications are done to the `stock.move.line` form
view too.
OPW-3577844
Part-of: odoo/odoo#144282
Before this commit, it was not possible to create a new picking on
mobile if this picking has multiple moves.
How to reproduce:
- Open Odoo on mobile (or on desktop but simulate mobile device with
devtools);
- Inventory > Operations > Transfers;
- Create a new transfer (a receipt for example);
- In its operations (moves), add a new product, then add a second
product.
- Try to save or validate the picking -> A warning prevent to do it,
saying you're trying to write on the field `product_qty` instead of
the field `product_uom_qty`.
What's happening:
For a unknown reason, the fields from the `stock.move` list view are
saved once a second move is created, even if we're using the kanban view
in the mobile version.
To avoid this issue, we force the `force_save` to be false for the field
`product_qty` in the kanban view. That's way, it prevents the issue.
OPW-3577844
X-original-commit: 818e7fcfd88fa9fe2927e327f4510b108a47c370
Part-of: odoo/odoo#144282
The tax with xmlid vat_0_import was missing its repartition
lines which caused validation errors.
This PR adds empty repartition lines to fix this problem.
closesodoo/odoo#151525
X-original-commit: 6ff955e1d7891d4848dc967b66d9d10310adf930
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
When flagging a post, moderators should see the flagged moderation queue
counter appear/increment.
We renamed the span in 21531bd9 and forgot to update this reference.
Task-3349373
closesodoo/odoo#151512
X-original-commit: 720d7b53e7d1a0944415a6c668f4eb3ba527dac8
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Florian Charlier (flch) <flch@odoo.com>
Commit[1] implemented a way to output an image as its raw representation
`<img src="data:image/png;base64......." />`
It is useful for integrating an image of a record not accessible publicly.
However the original commit forgot to allow the img node to handle the options
passed to the field. Classes in particular were absent
After this commit, the options are handled correctly, and the image in raw mode
has the right classes.
opw-3517861
[1]: f8b901d04bclosesodoo/odoo#151410
X-original-commit: dbb22351921629aad845e29ebfa8b4083b4e745a
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit:
When we have some text in selection and we move away from the selection the
the toolbar disappear.
After this commit:
The toolbar is still visible when we move far from the selected text.
task-3054229
closesodoo/odoo#151354
X-original-commit: cbcad3b85f78dd42f7e059471498009be27a9045
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
In 17.0 the calendar view was revamped and the boolean field `all_day` started
being rendered with the boolean_toggle widget. This widget, however, behaves
differently than the boolean widget without passing explicit props. This caused
the onchange call not to be made after this change. This commit fixes this by
passing the autosave option as False on the field.
task-3669879
closesodoo/odoo#148874
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Currently the version of the cryptography module installed with
the version of pyOpenssl 22.0.0 does not allow the execution
of the Odoo server on the iot for versions 15, 16 and 17.
With this change we explicitly give the version of
the cryptography module 36.0.2 which corrects this problem.
closesodoo/odoo#151504
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Before this commit, the displayed allocation
on the dashboard were all the ones linked to allocations
regardless of their validity period. This resulted with
an overloaded dashboard with leave types that are not supposed
to be displayed.
closesodoo/odoo#151306
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
When updating contracts, work entries are recomputed automatically for the employee linked to that contract.
However some contracts might not have an employee, which raises an error.
Added a check to recompute work entries only if the contract has an employee.
closesodoo/odoo#151190
Task: 3614495
X-original-commit: 3a4683ae8159bf405513a901b1fd3bba72a05fb7
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, since [1], the "small" class behavior of Bootstrap
was changed to use a fixed value instead of being dependent on the
context (using `em` units).
This was a bad choice, given the fact that the "small" class could
be used in the past with its previous behavior in custo but also in
default Odoo layouts, where it could be use in more legit cases that the
one Odoo currently offers: instead of applying the class to a whole
paragraph, applying it to part of a title.
In that case, since [1], we can have a big title ... with a very small
text next to it, which may be strange. Of course, the proper way to
achieve a big title with a smaller text next to it would be to not use
"small" but another hx font-size, but the legit bootstrap behavior which
is to use their "small" class is thus broken.
This commit keeps the current possibilities (big title with very small
text next to it) but does it by using new custom Odoo classes instead of
changing the Bootstrap "small" one. That way, legit custo in previous
versions (or trying to use default Bootstrap in this version) will be
supported.
Note that this commit will impact existing 17.0 users though: if they
actually configured a big title with small inner text... those will
become big title with slightly smaller inner text (the default Bootstrap
behavior). Worse: a big title whose size was reduced using the font-size
selector and choosing "small" will now become a big title. We think this
is worth the risk (see PR description for more visual details).
However, notice that "legit" use case of the "small" font-size in 17.0
will be kept untouched: e.g. adding a small text on its own or next to
a paragraph: the "smaller" Bootstrap behavior is now computed based on
the ratio of the configured base and small font-sizes.
Note that some additional "bugs" were found investigating this:
- Form descriptions use the "small" class for no reason and should
probably not be possible to customize ("font style"-wise) anyway.
- The use of the "small" *tag* should probably be reviewed in all Odoo
layouts and/or its interaction with the editor be fixed.
[1]: https://github.com/odoo/odoo/commit/194f73a9bbad8c3c3fb5c378e7bdfa704aaacdc0closesodoo/odoo#149590
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In module `l10n_ch` after this commit https://github.com/odoo/odoo/commit/7a06ed07814ab8d9192d3a7ec15aba7f90f7294d
`account_report_expression` with name `account_tax_report_line_chtax_solde_formula` will be
depricated but it can't be deleted by upgrade because it has dependent external values.
On this commit I removed that depricated external values of that expression
closesodoo/odoo#151426
X-original-commit: b26f2e24f3e70e26bc98aafe0e87735a1256a9cd
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
In some case, the author should be notified. For example, in the
case someone books or cancels an appointment. The current user should
be notified as it's a proof that the action worked correctly.
This commit prepare a method that can be overriden to allow this process.
task-3505819
closesodoo/odoo#151319
X-original-commit: 9dff32354b0b6534ad707160459a9cd2514965f5
Related: odoo/enterprise#55221
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
Steps to reproduces:
- Create two products one with UoM units and the other grams
- Create and confirm an SO with these two products
- Set quantities and validate the transfer
- Click "Print labels"
Bug:
only products with UoM units are printed because "quantity_by_product"
is overwritten with only those products
opw-3658993
closesodoo/odoo#151236
X-original-commit: d3c3e2013bd3ef2fe78c8f27b15daeb633c4d9a0
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Current behaviour before commit:
In a saved pad, putting cursor inside a link without
making any other changes makes editor dirty. As result
discard button appears on the top.
Desired behaviour after commit:
Now putting cursor inside a link without editing
doesn't make editor dirty and discard button doesn't
appear on top.
task-3607361
closesodoo/odoo#151094
X-original-commit: d7f89ca078ec21fe0db49ae5b01f21caecd6abfa
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Implemented 'Codice Fiscale' field in checkout address form, addressing
a key need for our Italian customers.
This enhancement:
- Adds an optional 'Codice Fiscale' field, available for both
individuals and companies.
- Ensures compliance with Italian e-invoice requirements.
This update is a step towards better adapting our system to specific
localization requirements, enhancing user experience in italy.
task-3623622
closesodoo/odoo#151484
X-original-commit: 79157cdc9396b1a84f70d455f211febbc505c66c
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Mohamed Erradi (moer) <moer@odoo.com>
The aim of this commit is to make the duplicate bill warning works in
edit mode.
This is a backport of some fixes that were done in the following
commit: cb694599583f5df1667984fee01bbcc4c8b2d409
Before the commit:
The warning couldn't be triggered in edit mode.
After the commit:
The warning is triggered as soon as the field is unfocused.
closesodoo/odoo#151451
Task-id: None
X-original-commit: 57c51b9c7b70cbc19071a8dfb67713a674caa0a0
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Co-authored-by: moerradi <moer@odoo.com>
Prior to this commit, using an online payment method with an image in
self-ordering mode resulted in an issue preventing the opening of the
mobile menu. The specific error encountered was:
`TypeError: Object of type bytes is not JSON serializable`
This issue arose due to the image field being of type bytes. Since the
image field is not necessary for self-ordering, this commit addresses
the problem by preventing the loading of the image for a payment
method, resolving the serialization error.
opw-3624798
closesodoo/odoo#151388
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Steps to reproduce the bug (starting from saas-16.4 only!):
- Go to the website app
- Enter edit mode
=> Bug: the editor toolbar appears for a few ms, then disappears.
This bug occurs since [1], whose original commit was actually merged in
16.0 with [2]. The reason the bug only appears in saas-16.4 and not 16.0
is because of [3].
Commits [1] and [2] change the elements that are considered "tab-able"
and thus the elements that can be auto-focused by the `useActiveElement`
hook. That hook is actually used when we enter edit mode since [4], as a
way to declare the editor as the active element so that keyboard
shortcuts work (as indicated by the related commit).
What actually happens thanks to the hook is that once we enter edit mode
the "Block" button of the right panel is focused. This is because it is
considered to be the first "tab-able" element (with or without [1]/[2]).
Then keyboard shortcuts work as expected as the right panel is focused.
However, since [3], the `useActiveElement` hook is called "too soon".
Indeed the right panel is not actually inside the "auto-focused" editor
container yet**. The result is that what is now "auto-focused" is the
editor toolbar***. Before [1], the element in the toolbar that was
focused was an invisible one, so no bug appeared. Since [1], we only
auto-focus visible elements... so we now focus a visible element in the
editor toolbar, making it visible during editor instantiation.
This commit fixes the issue independently of [3] (which is why this
targets 16.0: to consolidate the codebases). Actually, the use of the
`useActiveElement` hook added by [4] is useless. It was fixing the
issue at the time, but the real solution was to do what was done since
at [5]. Indeed, the keyboard shortcuts were not working because the
backend navbar was still visible (even if outside of the viewport) so it
was its keyboard shortcuts that took precedence. Since [5], the use of
`useActiveElement` actually has not benefit anymore. The editor is part
of the backend UI, the backend UI is still focused after entering edit
mode, shortcuts targeting the editor panel are thus working naturally.
Removing the use of the `activeElement` hook only has one side effect:
the "Block" button of the right panel is not auto-focused anymore...
which is not needed.
Notes:
- The `useActiveElement` hook also has another purpose: allowing cycling
using tab and shift-tab, it should work naturally as with the backend
UI anyway but mainly: tab and shift-tab do not seem to be working with
the editor UI anyway.
- Another hint that [4] was not right way to go is that this is the only
use of the `useActiveElement` hook in the whole codebase, except for
the framework use for dialogs.
- ** That should maybe be solved on its own, although maybe it is not
important and risky at best.
- *** The editor toolbar should not even be instantiated that way in the
first place since it will be attached to the right panel later... but
that is another issue.
[1]: https://github.com/odoo/odoo/commit/c631bf09b927003edc4c2b85e8790e8e2e8c044a
[2]: https://github.com/odoo/odoo/commit/57452ee59c3e33eaa219d8d7b8d82239fd33b722
[3]: https://github.com/odoo/odoo/commit/76d4f9811b756f0e57b0a33dbba534c900c7fe15
[4]: https://github.com/odoo/odoo/commit/b0108e1876a27e83231e176cdca3e2d67d6a2a9c
[5]: https://github.com/odoo/odoo/commit/cdc8d4c889b316664323afad0d848403960150d5
task-3686730
closesodoo/odoo#151373
X-original-commit: aa168b5583b9b437fcf83c2f7b2d256ec66e4c79
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
of check_company=True fields.
Suppose two models
class A:
company_id = fields.M2O() # not required
class B:
_check_company_auto = True
company_id = fields.M2O() # not required
a_id = fields.M20(check_company=True)
and the following code:
a = A.create({'company_id': 1})
b = B.create({'a_id': a.id, 'company_id': False})
The creation of B will fail because of the multi-company
checks, which is expected.
Nevertheless, since 0d30cc2bc9, the domain
of the field a_id would be:
(company_id and ['|', ('company_id', '=', False), ('company_id', 'in', [company_id])] or []) + ([])
which means that through the interface, if you create a record b following
the example above (no company_id on b), the evaluated domain would be empty,
allowing to select records of class A, even if they belong to another company.
Of course, this would lead to a multi-company error when trying to save the
record.
This commit makes sure that the right domain is applied on
check_company=True fields, even if the current record has no value
in its `company_id` field.
opw-3629374
closesodoo/odoo#151341
X-original-commit: aaddedc3bab4f16747fb0f71ae626d94f3975ee3
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce:
- Create a branch for a company (e.g. Branch X)
- Go to "Website / Configuration / Websites"
- Create or configure a website on Branch X (e.g. Website X)
- Go to "Website / Configuration / Settings"
- Select Website X
- Set "Display Product Prices" to "Tax Included"
- Create a product for a price of $100 and a tax from parent company (e.g. 15%)
- Go to eShop page of Website X
Issue:
On the eShop products list page, the price of the product should be "Tax Included" ($115),
but it is not. The displayed price is $100.
When accessing the product page, the price is correctly displayed with the tax ($115).
Cause:
When computing the prices, taxes from parent companies are not taken into account.
opw-3660156
closesodoo/odoo#151320
X-original-commit: cbea1dac9d5d30fb42912b4ec25061952cde67a8
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Sorting is being computed on each mounted select menu during the useEffect() hook since this commit: 8a44857.
This can lead to long wait times or browser crashes when there are many select menus with many options.
Before this commit, all of the select menu were sorted when the user select a value in one of them.
This is not necessary as the sorting is already handled in beforeOpen.
After this commit, no sorting is being computed in useEffect() anymore to avoid unnecessary computation.
A test has been added to verify the sorting happens when needed.
opw-3616438
closesodoo/odoo#151318
X-original-commit: f58b88383ce6a7439c02dbe761dc9025ddfe3b0a
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Co-authored-by: Luca Vitali (luvi) <luvi@odoo.com>
Create an ir.model custom (state = "manual" -- for example via studio) that has a mix
of manual fields (named x_...) and of base fields (originating from some mixin).
Unlink all linked views or object, and try to unlink that model eventually.
Before this commit, an error was raised because base fields couldn't be deleted, even though the table was empty.
After this commit, the deletion works.
Note that this commit is a fix of https://github.com/odoo/odoo/pull/130420/ , which added partial support for this
and a backport of 7550bcd61e which fixed the former PR in 17.0
opw-3558590
closesodoo/odoo#151282
X-original-commit: 3e84f3e9b0da397d82d5add0e37be58f0e30c7be
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Steps to reproduce:
1- Install Manufacturing module
2- Create 2 or more new WOs and make sure that their corresponding MOs is not planned
3- Go to Operations > Work orders
4- Mark all of those WOs and write a start date to apply on all of them
5- Check Planning > Planning by Workcenter 'you will not find the scheduled WOs'
Current behavior before PR:
When you try to mark more than one record in Work orders and set start date for all of them at the same time it will not be set therefore it will not be visible in Planning calendar. This is happening because if you are setting the start date for the first time it will call the function that sets the start date first before calculating the finish date so it will not pass the condition where it checks if both dates have values.
Desired behavior after PR is merged:
Now we are checking just the start date if it has value or not and to raise the same user error if the customer tries to delete the finish date we are checking this on change of the finish date from a value to null.
opw-3596100
closesodoo/odoo#151272
X-original-commit: 70394e616e5d75ee33ed048dbd7210c1926c63be
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>
Dependencies and other manifest attributes are not set for data modules.
Note: it's easier to reproduce issue in 17 since we have data module available
on runbot.
steps to reproduce (in 17.0):
- install an industry (ex: bar_and_lounge)
- uninstall a dependency of that module (ex: mrp)
before this commit:
- bar_and_lounge is not uninstalled if you uninstall mrp
after this commit:
- data model dependencies are handled the same way as 'regular' modules
opw-3660052
closesodoo/odoo#151256
X-original-commit: 12256bbc5981b06d7b77c133cc8f282ac03afba9
Signed-off-by: Nicolas Danhier (nda) <nda@odoo.com>
Signed-off-by: Pierre Masereel (pim) <pim@odoo.com>
Pablo Montenegro