product variable used in the rounding precision come from the upper
loop and won't work for all the quantites.

opw-3229080

closes odoo/odoo#121262

X-original-commit: ea923a08
Signed-off-by: Tiffany Chang <tic@odoo.com>

Steps to reproduce:
- Install CRM module and go to any lead view.
- Make sure we are in mobile mode, and the page was loaded in mobile
mode.
- Go to Extra Information, and try to change the sales team field.

Issue:
We got an error since we didn't have a proper view for this field in
mobile.

Solution:
Adding the proper `kanban_view_ref` as in similar fields will fix the
issue and let us change the field without error.

opw-3323976

closes odoo/odoo#126044

Signed-off-by: Maruan Aguerdouh Mohtar (magm) <magm@odoo.com>

Description of the issue/feature this PR addresses:
In sale, when threshold value of product is not exceed than upsell activity is
created while creating invoice. upsell activity is only create when threshold
value exceed otherwise not.

Current behavior before PR:
When creating an invoice, an 'upsell' activity is created on the sales order and
assigned to the salesperson even if the threshold has not been exceeded.

Desired behavior after PR is merged:
Do not create a 'upsell' activity unless threshold is exceeded.

Fix:
super class is invoke before checking the upsell and create activity. so
now, we prevent super method from creating upsell activity via passing
`mail_activity_automation_skip` context.

task- 3330815

closes odoo/odoo#126017

X-original-commit: 9232093d
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

Some account terms are mistranslated, this PR aims to fix these translations. The customer provided a table with the mistakes and suggestions. The customer’s suggestions are available in the ticket.

How to reproduce:
1. Ukrainian translation > chart of accounts > some terms are mistranslated

closes odoo/odoo#126001

Opw: 3247005
X-original-commit: c19472f1
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Matheus Leal Viana (malv) <malv@odoo.com>

With [1] and [2], the colorpicker / colorpalette were implemented. In
both cases, for the custom colors hue / saturation / lightness selection
we listened to mousemove/mouseup events on the whole body / document.
That is to be able to start dragging the color cursors from inside the
colorpicker to anywhere on the screen (the cursor being confined into
their own box of course).

Problems occur when iframes come into the equation. Indeed, from that
moment, listening to mousemove events on an unique document is not the
way to go as mousemove over inner iframes will be ignored. This should
not be the case anywhere in 15.0 (that this original commit targets).
The only iframe there should be the mass_mailing one and in that case,
the colorpicker is inside the iframe so it should not be a problem.
However, [3] (then fixed by [4]) were meant to tackle a similar problem
(although [3] seems to say the goal was to ignore mousemove outside the
iframe which is the opposite of what this current commit tries to do:
listening on the whole screen). However, by doing so, a memory leak was
created as the document on which the events were bound was not properly
cleaned as the `destroy` which unbinds the events was not adapted. That
is the main reason why this commit targets 15.0 (although, the solution
here still makes sense generically in 15.0 and should make the code
simpler and easier to understand).

In 16.0, however, the iframe situation is a problem: the website builder
colorpickers are now in the main document but the edited content is
inside an inner iframe. In that case, listening to the main document's
mousemove/mouseup events makes the colorpicker only work when not
hovering the edited content (which could be acceptable but not perfect).
Note that during that website builder refactoring, [5] worsened the code
of [3] and [4] to do exactly that. Later, [6] was made to solve an
unrelated problem and actually woke up that worsened code, not
understanding what the new undocumented `ownerDocument` option was for
(it will stay like this in stable from now on, as it will be not used
anywhere anymore... hopefully). Because of that, the situation became
the opposite: dragging inside the colorpicker did not work until the
edited content was hovered. And because of that functional fact, an even
more visible problem was created:

- Click on a snippet
- Select a custom background color using the hsl selection
- Hover a non custom color (like nearly always the case "by mistake"
  after configuring a custom color, your mouse just moves over the non
  custom colors) => your custom color is lost

This was because the chain of events that were listened inside the
colorpicker were gone (because of the combination of [5] and [6]). In
the end, this only revealed the shortcomings of the implementation in
[1], [2], [3] and [4]: we should not try to search which frame we have
to listen to: we should listen to the whole screen. This commit solves
the issue by listening to the top window document and all its inner
iframes, also fixing the memory leak mentioned earlier.

task-3332711

[1]: https://github.com/odoo/odoo/commit/29f0c0a186a9a60d6e5b7f026c305d689b6fc807
[2]: https://github.com/odoo/odoo/commit/99910b526ed792235a778863b993d10cf4e77cd7
[3]: https://github.com/odoo/odoo/commit/4fb33f7f8d6955a44fbb7c94c7d204e9baa09707
[4]: https://github.com/odoo/odoo/commit/f1b26335a286a47f685b7830db97c21e6fefd68b
[5]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af
[6]: https://github.com/odoo/odoo/commit/418c1178301e28b4bd1412da6d0558e219060830



closes odoo/odoo#125993

X-original-commit: 63bf363d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

opw-3316448

closes odoo/odoo#125892

Related: odoo/enterprise#42932
Signed-off-by: Francois Georis (fge) <fge@odoo.com>

Since [0], a currency field is required to be in the view in order to
compute the aggregate values in a list view. As it turns out, many views
in odoo ([1], [2], ...) didn't meet this requirement. In stable, views
are not updated automatically and it requires a manual intervention.

Even though the views should still be fixed, this commits allows falling
back on the default number of digits in case the currency is missing.

[0]: https://github.com/odoo/odoo/commit/f112e923ff18679b4bf546677f240f6bf83f3bb2
[1]: https://github.com/odoo/odoo/commit/eaec9f7c3c28e2ee9d42597052a21e6b2695cd60
[2]: https://github.com/odoo/enterprise/commit/5ca99702e44ef09aed504e93a302bfe43997193e

opw-3316448

Part-of: odoo/odoo#125892

*: account, event_booth, gamification, hr, project,
   website_event_track, website_hr_recruitment, website_slides

HTML fields that appear in the front-end can be modified using the
website editor. Some of them are sanitized in a way that breaks the
behavior of snippets that can be dropped within them.

This commit adapts the sanitization of those HTML fields so that the
snippets behave as expected.

opw-3267589

closes odoo/odoo#125650

X-original-commit: 477cd32c7924ce79e8f29cf567fbbc625f24534f
Related: odoo/enterprise#42802
Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Steps to reproduce:
- Add a form.
- Setup a conditional visibility on one field, using the "contains" or
  "does not contain" operator.
- Save.
- Open the HTML editor and voluntarily break the form by changing the
  "data-visibility-dependency" attribute to a random text (non existing
  field used as a dependency).
- Save => Crash on page load.

One customer apparently reached that case of receiving a `null` value
(actually possible when retrieving a form data which is an unchecked
checkbox for example) but combined with an operator which really
requires the received value to be a string... but not sure how this is
possible. In any case, it should not make the form crash: it's just a
problematic *visibility* dependency, it should not prevent using the
form. For now, let's prevent this case to crash and add an error in the
console so we may investigate the issue if it ever shows up in a test.

opw-3243345

closes odoo/odoo#125914

X-original-commit: 27144695
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>

In the course fullscreen view, a black overlay is
hovering the content on medium screen size and lower
when the sidebar is active.

Fix the black overlay which is still showing after
closing the sidebar. When the sidebar is close the
overlay shouldn't be displayed.

As the content is translated to the right and still
fully visible on medium screen size, a black overlay
isn't needed. Only show the black overlay for small
screen size and lower.

Task-3371743

closes odoo/odoo#125036

Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>

Previously, copy-pasted tables from other spreadsheet editors did not
keep their style once in our editor. This is simply because the way
style information is embedded in the HTML is not inter-compatible across
editors.

Google Sheets places all the cell's style on <td> tags, which can't be
styled in Odoo 15. This has been fixed by moving all possible style
attributes to a direct <span> children, which is created if necessary.
In Odoo 16 and forward, the styles are left on <td> tags.

Microsoft Excel defines the style in the standard <style> tag (in the
<head> of the HTML), using custom CSS classes on tags. We parse that
<style> and copy it to the style attribute of <td> tags with matching
classes. Those styled <td> tags are later handled as described above.

Libre Office makes use of deprecated <font> tags and its specific
attributes. Those attributes are mapped to equivalent values for the
standard style attribute. It also places eventual <s> and <u> tags as
parents of <font> tags, which means the strike or underline doesn't
inherit the style of the text. We invert those for nicer styling as is
the default in our editor.

Tests have been added for each of those aforementioned Spreadsheet
editors, ensuring we save exactly their style values that are compatible
with the Odoo editor, nothing less and nothing more.

Note that for v15.0, background color of cells is discarded as it is not
supported in our own editor. For v16.0 and on, it is supported and kept.

Task-3255167

closes odoo/odoo#124527

X-original-commit: b241c59982232b1a4b96518311ec12d81d5ad001
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

Previously, when copy-pasting HTML with styles on styleable tags, those
styles could still be removed by the editor if they had a default value.
This was supposed to be a way to keep the DOM clean and lighter.

However, styles with default values still serve a purpose when
overriding non-default values inherited by their parents. Therefore,
removing them was a conceptual mistake.

One example in the editor where this purpose can be served is in
tables where spans can override the style of the cell or parent span.

This commit ensures we no longer remove style attributes because of
their default value.

Task-3332955

X-original-commit: 0c097311
Part-of: odoo/odoo#124527

Remove button is shown when the view of our field is in kanban mode.

When our field is one2many it will delete the record and when our field is
many2one it will remove the record.

So many times user get confuse that they are deleting the record or removing
the record.

So to clear out the confusion this commit changes the label of remove to
to delete if the field is one2many.

A test was added to ensure this ux change.

Task-3185967

closes odoo/odoo#118702

Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>

Issue:
------
The "Launch Plan" button appears for an archived employee.
It causes a traceback.

Solution:
---------
Do not display the button for an archived employee.

opw-3366815

closes odoo/odoo#125896

X-original-commit: 6536a88b
Signed-off-by: Kevin Baptiste <kba@odoo.com>

Before this commit:

The mass mailing footer had no padding top.

After this commit:

Added 1rem / 16px of padding top to the footer.

Task - 3323881

closes odoo/odoo#121248

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

- steps to reproduce bug:
  In project.task sharing form view, When clicking on any of the stat buttons (subtasks or parent task)
  when you arrive on the actual task formview a MissingError saying 'missing record' appears
- Issue:
  The record loads accordingly but the Missing Error shouldn't appear

- Cause:
  It is coming from the project_sharing_form_compiler which gave the projectSharingId props to the ChatterContainer element
  but the projectSharingId is equal to the "props.record.context.active_id" of the action, and in the context of the
  chatter we want the active_id to be equal to the project_id, which was the case when we are coming from the KanbanView and
  sub-list views but when coming from the task stat button the active_id is equal to the task_id and the env can't find
  the document 'project.project' with the id of the task. (in portal.py _document_check_access())
- Fix:
  We simply change the projectSharingId to take the "props.record.contect.active_id_chatter" the give an
  active_id_chatter= active_id in the Project Sharing task_action which will always equal the Id of the project

Task-3284755

closes odoo/odoo#119832

Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

Before this commit, website and email editing was very limited on
devices that have a touchscreen. The blocks tab, the we-lists, ... were
unusable.
Example of issues (on a device that has a touchscreen):
- The users cannot drag & drop snippets in the page.
- The users cannot reorder the values of a multiple checkboxes field.
- ...

This commit allows to handle touchscreen events by translating them
into mouse events to allow users to fully use the editor.

opw-3195487

closes odoo/odoo#114485

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Post counts were not updated when a post was created or deleted
because of missing dependencies in the _compute.

Note that while "active_test" is included when counting without
specifying it, the field must be explicitly added to the `_compute`'s
dependency list to trigger it.

Task-3358143

closes odoo/odoo#125869

X-original-commit: f09291da
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>

We have introduced a new tag `website_nightly` which is linked to a
custom build on the nightly.
It has been introduced with this commit [1].

The goal is to extract the `external` tagged tests linked to the website
app to another special build linked to the website team.
Otherwise, we would not see when the test fail, as the `external` build
of the nightly is always red and we don't check why all the time.

Encapsulating this in a new build and linking to our team means that
whenever the test fail in a nightly, we will be visually warned on the
runbot homepage by a red warning, see screenshot on the PR of this
commit.

Sadly, before 16.4, as there is not yet `website_nightly` tours, the
build is considered failed, showing the error.
Another solution would have been to somehow disable this tour on Odoo
versions < 16.4 but it we opted for this solution as:
- It's simpler, no need to add yet another custom stuff in runbot
- It will work out of the box should be introduce such a test in those
  versions: we won't need to ask runbot to activate the test in another
  version, should we even think about it..

[1]: https://github.com/odoo/odoo/commit/a0d0afb20594aa103eb1d0476d53012b9821e861



closes odoo/odoo#125847

X-original-commit: 2402ce27
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>

On the Blanket Order PDF (as well as other purchase agreements), the
vendor isn't specified on the report while it is a required and
significative field on the purchase agreement.
Added it like in the purchase order PDF.

Also added in the Custom Description field into the PDF as it may
contain useful information as well.

Task-3358385

closes odoo/odoo#125554

X-original-commit: ee92e8c8
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>

Ever since iOS 16.4, going back and forth through a website with the
cache enabled, creates an error in the console which Odoo tries to
handle but fails to do so. Therefor a generic CORS error message
appears.

There is unfortunately no proper way to fix this bug on our end so
instead, this commit tries to mitigate the error by returning early and
not showing the traceback dialog.

I (ARD) have submitted a feedback through Apple's Feedback Assistant app
and will subsequently remove this commit when Apple releases an update
that fixes this.

opw-3281727

closes odoo/odoo#125463

X-original-commit: 2981378e
Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Since [1] an error is raised when switching the Mode of an Images Wall
from Float to Grid or Masonry while an image is selected.
The display of the size of the image is being updated while its option
panel is not there anymore.

This commit prevents this error from happening by setting up the grid
layout with clones of the images instead of the images themselves.
This leads to the construction of a new editor for the new image.

Steps to reproduce:
- Drop an Images Wall snippet.
- Switch Mode to Float.
- Select an image.
- Switch Mode to Grid.

=> Traceback.

[1]: https://github.com/odoo/odoo/commit/2cbb691a84ce186ddd34a2a4c76d95671ed6e834



task-2990053

closes odoo/odoo#125396

X-original-commit: ef3d8aa2
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>

Current behavior:
When you refund a downpayment in the PoS, the downpayment is not added
to the original order.

Steps to reproduce:
- Create an order in the sales app
- Open the PoS and make a downpayment for the order
- Refund the downpayment you just made
- Go back to the original order in the sales app, the downpayment is
  correctly added, but the refund of the downpayment is not added.
- The order should contain : The original product, the downpayment and
  the refund of the downpayment.

opw-3275708

closes odoo/odoo#125357

X-original-commit: 02a67b42
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>

The customer was having an issue where they would create an expense from an email with the wrong cost on the expense.
Then when they would try to change the price on the expense record it would seem find all the way up until the journal was posted.

Issue:
When creating an expense from an email the unit_amount is updated instead of the total_amount.
This would cause issues if you had an attachment because when you would attempt to change the amount through the front-end this unit_amount would never get updated because it was set and there was an attachment (line 265).
However, when you would create a journal entry from this expense, because it has the unit_amount != 0 it would provide the unit_amount instead of the total_amount.
Thus propogating the original number from the email even if it was updated between the time of posting and the creation of the expense from the email.

Solution:
Implement an inverse function on total_amount that will update the unit_amount to total_amount_company.
This will cause the unit_amount to stay up to date with the total_amount while also taking into account currency.

opw-3286372

closes odoo/odoo#122012

Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>

When the user will not get an HTTP response as 200 while retrieving the location
using OpenStreetMap Nominatim service, the logger error will occur.

The logger is updated to use the 'warning' level instead of the 'error' level.
This change reflects a less severe logging level for cases where a request to
OpenStreetMap fails.

sentry-4151622143

closes odoo/odoo#125809

X-original-commit: a73a65ef
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>

task-3372999

closes odoo/odoo#125209

Related: odoo/enterprise#42656
Signed-off-by: Kevin Baptiste <kba@odoo.com>

closes odoo/odoo#124897

X-original-commit: 39f23ac5
Signed-off-by: Josse Colpaert <jco@odoo.com>

Prior to this commit, when using the "Slide Hover" reveal effect on the
footer, Safari would glitch it scrolls and could result in unreadable
content.

This commit fixes this by a weird hack that seems to work. Adding an
element with a background-image and a background-attachment set to
fixed seems to resolve the issue.

task-3302302

closes odoo/odoo#125260

X-original-commit: 5766aefcd354e89094c8e650b29529301e39d49d
Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>

When hovering over an employee's photo (without edit rights) and the
image hasn't been loaded in the cache, the popover is positioned to the
right of the image. With a big image, the popover can be outside of the
page.

Steps to reproduce:
1. Install Employees and set a 4k image to any employee
2. Remove all the rights of Marc Demo on Employees
3. Connect as Marc Demo
4. Open the form of the employee with the 4k image
5. Hover on the employee photo
6. The image position is off

Solution:
Update the position of the popover when the image is loaded and restrict
the image width in the popover to the popover width

Problem:
When we try to find the best position to display the popover and the
image is not loaded, we will find that there is some room for the
popover on the right because the image has no height or width

opw-3281649

closes odoo/odoo#124794

Signed-off-by: Bruno Boi (boi) <boi@odoo.com>

When converting inline svg shapes to images, we checked if the source
ended with ".svg", which is not enough, as it can include query
parameters (eg, .svg?color=red). We now simply check if it includes
".svg" instead.

We also need to make sure we didn't make a clone of the image in an mso
before converting it, as the source wouldn't get converted in the mso.

closes odoo/odoo#125764

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

After preventing "async" code on link tools update in [1], the
`'link_tools'` test is still failing because of another race condition
issue:

The click on "save" after setting the link style to secondary triggers
an event handler that destroys the link tools widget (see `Wysiwyg` >
`destroyLinkTools()`), leading to calling the `_removeHintClasses()`
method first (both `_addHintClasses()` and `_removeHintClasses()` will
disable the editor observer while adding / removing the link hint
class to prevent their mutations to be recorded...).

Since the observer is inactive, the changes made to the link using the
link tools will not be processed, and the block will not be set as
`.o_dirty`.

As mentioned previously, (and starting from [2]) the editor observer is
inactive (while handling the `.oe_edited_link` class) in order to
prevent recording the mutations... But since [3], the editor had the
ability to prevent some classes (including `.oe_edited_link`) from being
taken into consideration in the `filterMutationRecords()` method...

The goal of this commit is to fix this race condition issue by simply
keeping the observer activated while handling the link hint class...

Remarks:

- These changes are supposed to fix the `link_tools` test that fails on
16.0+, but 15.0 was targeted here since the `.oe_edited_link` class is
ignored by the editor starting from 15.0 and also to prevent any future
issue linked to disabling the observer...

- Adding and removing the `active` class should not affect the history,
since it targets the `linktTools` toolbar button...

[1]: https://github.com/odoo/odoo/pull/109250/commits/f42715fdc89a6a88446c5f88ecec29e6a9c96fe1
[2]: https://github.com/odoo/odoo/pull/90064/commits/26377710a6e3ad61a8c266e9f7c0b8ade98f657d
[3]: https://github.com/odoo/odoo/commit/1c25ddb42393b136cac2a0ee0b9b7280fd803e7d



runbot-18747

closes odoo/odoo#125755

X-original-commit: 6a15cbe7
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

Use case:
It happens that a product is consumed in different operations.
So it needs two distinct BoM lines. Since commit [1] the stock.move
in pbm are not merged. However [1] was design for kit.
In our case we would like to have only one stock.move for all the
quantities.

The fix is not perfect because it won't work if we confirm at the
same time a move with a kit and without it. But at least it will let
people using MO without kit has the correct behavior

+ remove a duplicate of the function

[1] commit 741d2fe9

closes odoo/odoo#125733

X-original-commit: f7414901
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

The purpose of this commit is to review the responsiveness and spacing
of some settings that were visually broken.

The nested checkboxes were growing too much on smaller screens
making the content overflow.

This commit adapts these checkboxes settings to make them more readable
and consistent.

Task-3113372

closes odoo/odoo#108902

Related: odoo/enterprise#35323
Signed-off-by: Tiffany Chang <tic@odoo.com>

In the website settings, one of the fields allows you to switch settings
from one website to another. Unfortunately, as soon as the user did this
the record was considered to have changed (dirty) and therefore required
a save when it wasn't necessary. The previous commit prevents the header
settings (like the website switcher) from dirtying the record. This was
really necessary because as soon as a user had several websites, it was
impossible for him to access certain settings on all these websites
(except the first one). As soon as the setting performed an action, a
save was required (because the record was dirty) and the user was
redirected to the settings again.
Steps to reproduce the issue before the previous commit:

Install website
Have multiple websites
Go to Settings > Website Settings
Change the website
=> The user is notified that the record has changed and needs to be
saved, which is not true. So far it's annoying but not critical, but if
the user continues:

Activate the "Extra step during checkout" option
Click on "Configure Form"
=> The Save/Discard dialog appears because the record is dirty.

Click on "Save"
=> The user is redirected to the settings page again and cannot access
the form configuration of the second website. (it is the same issue for
most of actions).

The previous commit fixes the issue and this commit adds a test to
ensure that the users are able to change settings of multiple websites.

task-3265100

closes odoo/odoo#125550

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

When a user changes a header setting, the record should not be marked as
dirty. If the user clicks on a button, the save dialog should not be
shown.

Next commit will bring a functional test and "steps to reproduce" of
this issue in website.

task-3265100

Part-of: odoo/odoo#125550
Co-authored-by: "Guillaume (gdi)" <gdi@odoo.com>

closes odoo/odoo#124901

Signed-off-by: Josse Colpaert <jco@odoo.com>

The ZATCA edi has an onboarding process which happens per journal.
A private key is generated for the company and with the data from
the company and journal a CSR is made to get a certificate to sign the
invoices.  In that process that contains multiple steps (see account_journal.py),
we also have to send the compliance files which are some example (simplified or not)
invoices/debit and credit notes.  We have a separate folder with those files
and also use them in the tests.  For the onboarding, they still need to be signed however.

For the sending of the customer invoices themselves, UBL 2.1 is used, but
with ZATCA style adaptations.  That is why we inherit from that class
to be able to add those specific adaptations.  This UBL needs to be
signed XadeS and in this case we need to do the hash with the sign information
present but with empty tags.

For ZATCA invoices, as is the case with Ticketbai, the previous hash is needed
for the next invoice and is stored per journal.  (so we have a chain of hashes)

Tests written by Simon (smdc)

Part-of: odoo/odoo#124901

For SA, we need to be able to filter on the taxes exported, as
certain taxes should simply not be reported in the UBL.

Part-of: odoo/odoo#124901

+ to comply with ZATCA provide a better demo VAT number

Part-of: odoo/odoo#124901

Currently, when selecting tags for a task with no project (private
task) on mobile, a warning is displayed. On top of that, the amount
available tags is way more limited than in classical view and the
selection of some exesting tags is impossible.

Steps
=====
1. Warning when selecting tags
- Install module project
- In mobile view, go to the view "Tasks -> My Tasks"
- Open or create a private task (task with no project)
- Click on the tags field

A warning is displayed (on the server logs) stating:
"The domain term '('project_ids', 'in', False)' should use the '=' or
'!=' operator."

2. Limited tag choice
- Install module project
- In mobile view, go to the view "Tasks -> My Tasks"
- Open or create a private task (task with no project)
- Click on the tags field
- The tags that are only related to project(s) are not displayed in this
  view
- Try to create a tag with the same name than an existing tag that does
  not appear.
- A traceback is displayed because this tag already exists.

Cause
=====
As noted from the test of expression.py, M2M fields in the domain should
be compared to list of elements. It is not the case here. When a
project_id exits in the context, nothing happens, but there exists a
check in the ORM to ensure that '=' or '!=' operator is used if the
second element of the domain leaf is a boolean. In this case, there is
not project_id set in the context for private task, resulting in
the previous warning (False used instead of project_id).

Fix
===
We use the improved implementation of _name_search to get the ordered
list of id of records project.tags to display. This list has the
advantage to not be restricted to the current project, while still
presenting the tags of the current project at the top of the list. The
mobile view uses the method search_read to get the list of project.tags
record values, therefore we call the _name_search in this method and use
an optimized sorting function to sort the resulting records accordingly.

task-3302370

closes odoo/odoo#110814

Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>