*: mass_mailing_themes, website_mass_mailing
This commit adds TikTok to the already existing social networks in all
email marketing templates (droppable blocks and default mail templates).
task-3235451
closesodoo/odoo#116837
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
*: website, website_blog, website_event
This commit adds the TikTok social network to the other social networks
stored in DB. Thus, users of the Website application will be able to
reference their TikTok page on their websites. This commit also updates
the different templates and the social media block to integrate this new
social network.
task-3235451
Part-of: odoo/odoo#116837
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#116371
Task-id: 3052677
Signed-off-by: John Laterre (jol) <jol@odoo.com>
When receiving an email on a mailbox with an alias that triggers the
creation of invoices, 4 bugs could occur.
1. If the xml received contains replacement characters (U+FFFD �), and
the charset of the part of the email is "US-ASCII" the encoding of the
string will fail, preventing the rest of the flow to be completed. Be
more resilient, encode the string and ignores these characters if this
case occurs.
NB: sometimes, the charset is omitted for a Content-type: text/xml. This
is valid but not recommended (see:
https://www.ietf.org/rfc/rfc2376.txt). In this case, the default used is
"US-ASCII". This means that any non-ascii char will be lost (they are
replaced by the replacement character: �, see:
https://github.com/python/cpython/blob/3.10/Lib/email/contentmanager.py#L67)
when decoding the attachment.
2. When the xml attachment is created in Odoo, the mimetype is
'text/plain' (rather than 'application/xml'). Thus, the
`_decode_attachment` needs to be more flexible when guessing the type of
the attachment (to know which function to use to read the content of the
attachment and create the invoice).
3. When creating an invoice from an email with an xml attachment, the
xml is attached as the `message_main_attachment_id`. It's only later on
that the content of the xml is read and we possibly find the PDF in
base64 inside. When creating the PDF attachment, it was not set as the
`message_main_attachment_id`, so the PDF was not rendered on the right
part of the invoice form view. Add a clause to replace the
`message_main_attachment_id` in such a case.
4. When the xml attachment represents a credit note, the move_type of
the invoice created by the email alias needs to be changed. Indeed, the
invoice is created before decoding the attachment, so we can only change
the `move_type` later.
opw-3144519
opw-3149649
closesodoo/odoo#121076
X-original-commit: 1e193a92b9c84e75b958985f8067873b90f686e0
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
Due to numerous client complaining about their automated scanner not
seeing the CSP header on the http request, we add it for good mesures
opw-2793379
closesodoo/odoo#121098
X-original-commit: 70a54ac604cf2aeef33d11b95851e35dd463727f
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Prevent crashing when there is no VAT for an autralian partner for A-NZ
Bis Billing 3.0.
closesodoo/odoo#121093
X-original-commit: 58efba364364e7d040bc8b9bf5fb2fb897d7cb30
Signed-off-by: Laurent Smet <las@odoo.com>
Based on Allegro-IT's PR https://github.com/odoo/odoo/pull/112159
with several adjustments and fixes (renamed XMLIDs, taxes, fiscal
positions, VAT report).
closesodoo/odoo#121073
X-original-commit: 815a817ff53760d57f978fd88b529a8b38bda62d
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
Readonly email fields break the layout if the value is long enough
Steps to reproduce:
1. Install CRM and Studio
2. Go to CRM and open any lead
3. Change the lead email and make it too large for the field size
4. Toggle Studio, in the View tab, uncheck 'Can Edit'
5. Close Studio
6. The email overflows its expected position
Solution:
Put the email field inside a grid layout div
opw-3248361
closesodoo/odoo#121020
X-original-commit: 855e72af9907cbfdcf1a0debd8011be9934eeb8f
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
on clicking the graph view of the Partnership Analysis, currently the tree
view and form view is opened. actually the tree and form view for this model
are not defined in the code and thus the end user get the tree view with only
ID field in it.
As those view have no sense, prevent from jumping on those.
closesodoo/odoo#121007
X-original-commit: 82a9900633b2cfc98d1d96146645646f0d5d70d2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, a test spawning a datetime field in an editable list
view would crash randomly based on the assertion that a datepicker
should not be in the DOM after clicking on that field.
This is wrong however since a click triggers a focus, which is the
condition for the picker to open, althouth this mostly happens after an
additional animation frame because of the way the list works (field
becomes editable on next render -> picker then opens on next render).
This commit adds a nextTick delay after clicking on the cell to restore
the intended behaviour, which is to wait for the picker to open.
closesodoo/odoo#120999
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
When one customize a course by adding the 'buy now'
button. Both the 'Add to cart' and 'Buy now' button
doesn't fill the container width.
This commit fix this by changing 'btn-block' class
by 'd-block'.
See commit eee625bbb0
Task-3299234
closesodoo/odoo#120986
X-original-commit: 77d8bc4e9ed5925967294e89440cf667b26b4cbf
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce the bug:
- Connect with the company A
- Create a consumable product “P1”
- Create a receipt transfer with this product
- confirm the transfer
- Come back to the product form
- limiter le produit que a la “Company B”
Problem:
no user error triggered
Go to inventory > operation > transfer: a Traceback is triggered
Before this commit, there is no verification while changing a product's
company for consumable. That can lead to an issue where some operations
cannot be done because of access errors. To avoid that, this commit
prevents to change the product's company if some move lines for this
product exist in another company.
opw-3300559
closesodoo/odoo#120983
X-original-commit: a6666de7f492f9f94abc23a080134dd473d0dddc
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Issue 1: before this patch it was impossible to create a manual model
marked as "Is blacklist". The reason is that a blacklist model
implicitly need an `email` field, but such field is impossible to add in
a manual model: the field must start with `x_`.
Solution: append `x_` to the implicit email field. Note, in principle
the user gets an error if `x_email` is not present. Solved by adding the
field when creating the custom model. Ideally we should show some hint
in the interface to make it more user friendly. That is out of the scope
of this patch.
Issue 2: when we have a manual model that is mail blacklist it's
impossible to create its model class. We get an error because the MRO is
not correct. The reason is that we are adding `mail.thread.blacklist`
_after_ `mail.thread` in the `_inherit` list. That list is used to
generated the `__bases__` of the model class[1]. According to Python's
MRO rules[2], since `mail.thread.blacklist` appears after `mail.thread`
as parents of the custom model class this order _must_ be respected. But
`mail.thread` must appear _before_ `mail.thread.blacklist` because the
latter inherits from the former. This is a contradiction and the MRO
algorithm cannot succeed. To put it in a simple example:
```py
class A: pass
class B(A): pass
# This fails:
# class C(A, B): pass
# The right order is:
class C(B, A): pass
# Equivalent to:
class D(B): pass
# C and D have the same MRO linearization excluding themselves
assert D.mro()[1:] == C.mro()[1:]
```
Example traceback:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/14.0/odoo/service/server.py", line 1201, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "/home/odoo/src/odoo/14.0/odoo/modules/registry.py", line 89, in new
odoo.modules.load_modules(registry._db, force_demo, status, update_module)
File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 464, in load_modules
registry.setup_models(cr)
File "/home/odoo/src/odoo/14.0/odoo/modules/registry.py", line 263, in setup_models
env['ir.model']._add_manual_models()
File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/ir_model.py", line 430, in _add_manual_models
Model = model_class._build_model(self.pool, cr)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 585, in _build_model
ModelClass.__bases__ = tuple(bases)
TypeError: Cannot create a consistent method resolution
order (MRO) for bases BaseModel, mail.thread, mail.thread.blacklist, base
```
Solution: check if a model inherits from `mail.thread.blacklist` first.
There is no need to add `mail.thread` if inheriting
`mail.thread.blacklist` because the inheritance is already implicit.
This issue was observed during upgrades. We convert custom models and
fields into manual to allow upgrading without custom code. This causes
issues because the MRO error appears when a custom model inherits mail
blacklist.
[1]: https://github.com/odoo/odoo/blob/02f820fb0eaddbb3a4269a0967184c8aaf52c363/odoo/models.py#L585
[2]: https://www.python.org/download/releases/2.3/mro/closesodoo/odoo#120977
X-original-commit: 8848bb57ff7f086d801178c582d7f6371eeb8479
Signed-off-by: Christophe Simonis <chs@odoo.com>
Signed-off-by: Alvaro Fuentes Suarez (afu) <afu@odoo.com>
In delivery address, `country name` and in shipping method, `country name`
will be same and no zip in delivery address. While creating new sale order
along with product and clicking on "Add shipping", error will be generated.
Steps to Reproduce
-Install `sale_management' and 'delivery' modules
-Go to the settings and enable the 'Customer Address'.
-Go to the settings and enable 'Shipping Methods' and configure it.
-Select a shipping method and go to the 'Destination Availability' tab and
set to the 'Countries' and set to 'Zip Prefixes'.
-Create a new customer and add the delivery address of the customer in
res.partner.
-The delivery address and shipping method of the 'Countries" or 'Country'
name should be the same.
-Set the 'Zip Prefixes'
-Set the delivery address of zip code null.
-Create a new quotation and add to the customer and delivery address
-Add to the product in the sale order line.
-Click on the 'Add Shipping' or 'Update Shipping Cost' button.
A trace back will be generated.
Applying this commit will resolve this issue.
sentry-4147077852
closesodoo/odoo#120968
X-original-commit: 60d5c7d5668da542e251d7d6fb8774043cfddea8
Signed-off-by: Tiffany Chang <tic@odoo.com>
Partial revert of b15116179e71040ffa01bb35161e32b16aac477d .
This fix introduced a new bug: when creating an write-off with taxes from the bank reconciliation widget, signs were all inverted in the tax report, because that commit was forcing the values of tax_tax_invert in a wrong way.
The proper fix is to fix the computation of the is_refund field in community, so that negative repartition lines are taken into account ("debit" is a refund for a "sales" tax only for positive repartition lines, for example).
Community part is in https://github.com/odoo/odoo/pull/120152closesodoo/odoo#120924
X-original-commit: 67e789074cb00b9db6e3fd83ef92ed712b28edfb
Related: odoo/enterprise#40856
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
Cash basis taxes use a distinct transition account on their tax lines; the tax account set on the repartition lines is only used when the payment is received, on the cash basis move.
In enterprise, the bank reconciliation widget allows setting a tax on the manual write-off done for a statement line. When doing so, we expect the tax to behave just like on an invoice. For cash basis taxes, this means the "final" tax account has to be used instead of the transition one ; it wasn't the case.
OPW 3255511
X-original-commit: 991fa46081296c3560bd7ca195996693a81a46b8
Part-of: odoo/odoo#120924
Before this commit, the Order button wasn't displayed due to an
incorrect comparison with a `LazyTranslatedString` object
(`this.props.actionName`). This commit resolves the issue by ensuring
proper comparison of `this.props.actionType` with the string "payment".
Step to reproduce:
- create a pos_config (bar)
- active a printer on it
- open the PoS bar
- select a table and add some product
- The orderline are green but there's not order button.
opw-3300533
closesodoo/odoo#120846
X-original-commit: a04f8ebdfb724c74531f38927a655e6aae86bc26
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allows for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#116381
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allows for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#116379
Task-id: 3052677
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allows for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#116377
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allows for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#116374
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allows for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#116372
Task-id: 3052677
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#116365
Task-id: 3052677
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#116362
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#116360
Task-id: 3052677
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#115521
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#115487
Task-id: 3052677
Related: odoo/enterprise#38285
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#115478
Task-id: 3052677
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#115272
Task-id: 3052677
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Before this commit, if we try to change the action from a form view
a new record in an x2m and the new action fails to mount, then the new
record in the x2m will always have a virtual id even if it has already
been saved on the server side.
Why:
When you try to exit the form view, the form view will save the record
and not read the record because you leave the view (in the beforeLeave).
But in our case, we fail to mount the new action and so we will stay on
the form view without it doing a read to know the id of the record added
in the x2m. So the view thinks that the x2m still contains a virtual record.
Solution:
Going back to action should rebuild the whole compound. To cause this,
we'll restore the last controller.
How to reproduce:
- Going to a form view with an x2m field and a widget performing a doAction
- Add a line to the x2m
- Click on the widget to change the action
- New action fails to mount, it returns an error
- Close the error dialog
- Edit another field
- Save the form view
Before this commit:
The new line in the x2m is duplicated.
After this commit:
The new line in the x2m is unique
opw-3193765
closesodoo/odoo#120765
X-original-commit: 72f68e2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This pr fixes a bug where a validation error occurs in the timesheet
wizard.
Indeed, when the user enter manually a start or end date in a workorder,
the whole MO becomes "plan".
The problem here was that if the user opens the wizard of another
workorder (on the same MO) that has no start/ end date set, and then if
he saves (no matter if he changed something), it will trigger a
validation error because the start and end date of the workorder is
required in that view if the MO is planned.
closesodoo/odoo#120386
X-original-commit: c9728858aa46e6cb1a3d39cbc8da8e175007e456
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
On the manufacturing order, modifying the timer value does save it's value
in db but does not actualise it in the front.
The "rerun" condition is already checked in MrpTimer and does not need
to be checked in MrpTimerField
closesodoo/odoo#120385
X-original-commit: a8cfa1d26ef84aa6690d3cfa8b98b6cecf4f27d9
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Description of the issue/feature this PR addresses:
Before this commit assign_me button and clock icon from start button is shown in
project task , project sharing as well as helpdesk ticket.
This commit remove assign_me buttom and clock icon from start button in project
task, project sharing and helpdesk ticket.
task-3292056
closesodoo/odoo#120378
Related: odoo/enterprise#40630
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commit introduces a "_is_portal" method complementary to the existing
"_is_internal" and "_is_public".
The goal is to ease usage through the code base and be able to easily
distinguish our 3 main use cases: public, portal and internal users.
Task-3056280
closesodoo/odoo#120827
Related: odoo/enterprise#38575
Related: odoo/upgrade#4575
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently the summary and description in event ics file generation
are set directly, with a condition in case the event is an appointment.
We make these two ics 'fields' use a getter so that it can be
overriden inside appointment instead.
In addition we remove the special formater for 'online events'
as it is only used for appointments, which does not use it anymore
as of this task
task-3232952
closesodoo/odoo#116211
Related: odoo/enterprise#38570
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#115268
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#114838
Task-id: 3052677
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#114755
Task-id: 3052677
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#114700
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#114696
Task-id: 3052677
Signed-off-by: John Laterre (jol) <jol@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#114694
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes names so that it's more clear for users
closesodoo/odoo#114673
Task-id: 3052677
Signed-off-by: John Laterre (jol) <jol@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we have changed the Taxes names so that it's more clear for users
closesodoo/odoo#114653
Task-id: 3052677
Related: odoo/enterprise#37914
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes names so that it's more clear for users
closesodoo/odoo#114571
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the tax name of generic taxes
closesodoo/odoo#114537
Task-id: 3052677
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Before this commit, when the user changes the state, the followers
receive a notification about this change. Since the label of the
state is no longer customize by stage, the followers cannot know
in which stage the task is before clicking on the link to go to
the task form view. And so, if one of those followers has to
check the task in a specific, he has to click on the link in
the notification to know in which stage the task is.
This commit fixes the issue by adding the curent stage in the
notification to inform the user who received the notification
in which stage the task is when the state has been changed.
task-3284597
closesodoo/odoo#120959
X-original-commit: d78c79d9a9f8ac108251c57c732cfb5b71b53fd5
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Since [1] when the fuzzy search was introduced on website pages, the
filtering on most specific pages only happens at the end of the search
operation. Because of this, the search happens on pages that would be
excluded anyway, the limit might be wrongly applied and the count might
be wrong.
This commit makes the page search begin by keeping only the most
specific pages, then performing the actual search within those pages.
Steps to reproduce:
- Install `website` only and drop a search snippet.
- Search "ax".
=> No results found, but the "All results" link is displayed.
[1]: https://github.com/odoo/odoo/commit/7559626c54e34b41e1549e28276a650accec6986
task-3203794
closesodoo/odoo#120950
X-original-commit: 9725a14be22ad0f20bb6591054b60d91663ca88f
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
In the case of draft pickings/MOs, the reception_report_main
component's "Assign All" button was NOT disabled, which could result
in an IndexError if the button was pushed. Note that this issue does not
occur for the "Assign All" button within a table because the button is
correctly not shown at all when there are no assignable lines within it.
Noticed during task: 3046178
X-original-commit: 403d1ba5839d6073ee6321e77863f928336158ba
Part-of: odoo/odoo#120935
Guillaume (gdi)