Have a form view with a one2many list with one record inside.
Click on it to open it. The form view that will open must also have a one2many list
Before this commit, there was a crash because the information of the main record's view
was not propagated to the form view of the opened record. Generally speaking, env.config was lost.
After this commit, we propagate correctly the config.
closesodoo/odoo#96618
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit in tests, when creating a view with makeView, the same env was shared for services, view and
main_components_container. This is rather wrong as bugs in prod could not be reproduced in tests.
For example: env.config was present in the env for every services and components, this is wrong as
only View must receive it in its env.
After this commit, makeView separates the env for services and top-level components from the one dedicated for View.
Part-of: odoo/odoo#96618
This commit will trap the focus on the dialog, this will avoid modifying
a background record when a dialog is open. Trapping the focus on the
dialog is a well-known technique for modals (dialog).
closesodoo/odoo#96361
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Until now, an invalid PDF file would generate a traceback
during the export, which is not very user friendly.
The export happens when on the vendor bills list view,
by selecting one or more bill(s) that were generated
by the OCR (via the 'Upload' button),
clicking on 'Print' then 'Original Bills'.
The goal here is simply to catch those errors and display
a slightly more helpful message.
closesodoo/odoo#96935
X-original-commit: 7e7bd50403b6f5e2dabc39caf5fddb57d7052ebc
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Steps to reproduce:
- go to Inventory > Operations > Inventory Adjustments
- Select at least one product
- Click on Request a count; A dialog box containing a form should appear
- Select a user other than the current user
- Make sure to check "Set Current Value"
- Click "Confirm"
You should see that the user you selected is not the one assigned for
the count. Instead, the count is assigned to the current user.
This is happening because currently, calling
`action_set_inventory_quantity` also sets the user as the current one
if the quantity is not already set.
opw-2924694
closesodoo/odoo#96914
X-original-commit: f2b79bc4c6198aacca33eea8905fd62c629706a1
Signed-off-by: Tiffany Chang <tic@odoo.com>
Since eb67feb5 we had to redo the hack to read fields from public user and set them in hr_employee.
However in this hack we used `_read`, which doesn't fill the cache with fields that are not stored,
which caused a cache miss when reading the field `avatar_128` from hr.employee, to display the image of
the manager in the kanban view of hr_appraisal.
This fix uses `read` instead.
closesodoo/odoo#96889
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Before this commit, the buttons without classes in a button_box were
assigned the default btn-secondary.
Now, the default class for the buttons without classes in a button_box
is the class oe_stat_button
closesodoo/odoo#96881
Signed-off-by: Géry Debongnie <ged@odoo.com>
With the merge of the new views, we introduced an owl directive which is
t-call-context, that allows a t-call to execute in a controlled context
that is not the context of the component itself. In doing so, we forgot
that some existing templates rely on the presence of the env in the
rendering context for things like knowing if we are in debug mode or if
the device is small/mobile.
This commit fixes that by simply adding the env to the rendering context
of tooltuips.
closesodoo/odoo#96875
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit, the `callParticipantCard` model was used separately
for both the main session and the multi-tile views
(`CallSidebarView`/`CallMainView`), this commit makes so that each
multi-tile view has its own list of tiles.
part of task-2692836
closesodoo/odoo#96868
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
On the commit 69dcdd4, the order='create_date desc'
was removed and the way of getting the MO for the notification changed. Now, the context is used, it should be written_after instead of written_date.
(The MO created is correct, only the notification is wrong)
OPW-2877457
closesodoo/odoo#96856
X-original-commit: b80287b265a4c01babedcbb58459c35d36a48066
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This removes an extra request, targets fetched messages more reliably and
simplifies the code.
task-2847909
closesodoo/odoo#96840
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Previously, unnecessary space was present horizontally
around the status circle. This space has been adapted
to improve the style of the widget in views.
closesodoo/odoo#96831
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Before this commit:
When we put the text direct in td and try to color it with design toolbar with
text color then text in normal should change the color.
After this commit:
When we enter the text direct and try to change the color with design toolbar
then it will change the text with defined color.
Task-2843065
closesodoo/odoo#96830
X-original-commit: 76fd633ab78d5cb47c990063040d6d1e9708df2d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit fixes an issue with the ImageUrlField
widget. When no value was given, the image displayed
a broken file instead of being empty. A test
has been added.
closesodoo/odoo#96820
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Form views in dialogs should not display a control panel. Before
this commit, they did. To fix the issue, we reworked a bit how we
pass to the Layout component its "display" information (e.g.
whether it should display a control panel, and which parts of it).
Before this commit, it retrieved this info from the searchModel, in
the env. This doesn't allow a specific view to override it, for
instance the form view when it's in a dialog. To ease this, we
changed the Layout component s.t. it now takes a "display" props,
and no longer looks in the searchModel. Each view thus needs to
pass this as props.
closesodoo/odoo#96818
Related: odoo/enterprise#29857
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Previously, when the name attribute was set on a notebook in a form view
arch, we would pass that as a prop to the Notebook component, but this
prop is not supported by the component, so it would crash in debug mode
when validating the props. This commit fixes that by simply not copying
this attribute to a prop as it is useless.
closesodoo/odoo#96814
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: website, website_mass_mailing, website_payment
When an unsafe snippet is dropped into a sanitized HTML model field, its
unsafe content gets removed on save.
We need a way to mark snippets as being (in)compatible with
sanitization. It cannot be automatic, as, for example, the snippet
introduced at [1] contains an iframe but is compatible with
sanitization.
In 13.0, we will temporarily set up an automatic mechanism that marks
existing snippets containing forms as being incompatible with
sanitization.
In 14.0 a distinction between full sanitization and form-tolerant
sanitization introduced at [2] is added with this forward-ported commit.
This commit prevents unsafe snippets from being dropped into sanitized
HTML model fields.
The "Form Builder", "Product Search" and "Product Search Input" blocks
are now prevented from being dropped or moved into form-sanitized HTML
fields.
To do this, this commit introduces a new `t-forbid-sanitize` attribute
on the `t-snippet` tag. It can have the value `true` to prevent it from
being dropped into any sanitize fields, or `form` to specifically limit
to form-sanitized fields.
Steps to reproduce (in 13.0):
- Go to a product page
- Drop a "Product Search" snippet into the product-specific section of
the
product
- Save
=> The form was removed.
[1]: https://github.com/odoo/odoo/commit/c2e9bd0e60014b6a42931cf300e0f89f8cf7c225
[2]: https://github.com/odoo/odoo/commit/388c222c6c4bb7e2fe3e67009b248359ae0fd3db
task-2829961
closesodoo/odoo#96812
X-original-commit: 9eaba23781766730b06e936dbd9c5d0c28c909c6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
_* sale_management,sale_stock
Steps to reproduce:
- Install eCommerce
- Enable at least one more language
- Get an attribute with translations done (creation mode : never)
- Get a product with this attribute
- Go to the shop and add the product to the cart
- Go to the summary page and change the language
- Attributes fields aren't translated
Explanation:
This commit reverts the fix commit 47777ce1a7ee189c9328f53143abe492e861779e
that set the language of this description variants in function
of the order partner lang. We move where the language is added
in the context so that other cases like website_sale still have
the right translations.
opw-2790240
closesodoo/odoo#96811
X-original-commit: 9d3ffc9a1d817313764bc4b94f75711fd753fbc3
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
Cause:
The test fails because there is some demo data that added additional
website(s) and when trying to retrieve the current website without
domain, it might retrieve the wrong one.
Solution:
Unlink unused website(s).
opw-2899680
closesodoo/odoo#96810
X-original-commit: 45dfbae7301effe0d96163d67218a7854c3bde6f
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit fixes the API of the Notebook component
that mixed props of page templates with its attributes
(isVisible, title and index). Mixing page props and
attributes was confusing. Tests have been adapted
to reflect those changes.
closesodoo/odoo#96807
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Only youtube and dailymotion were able to add this property to their
video. Maybe it was not supported by vimeo back then, but it seems to be
supported now.
It improves the vimeo youtube in two ways:
1. For background video, the controls are now hidden. There were visible
for a few seconds before this PR which is not ideal
2. For non background video, there were no way to hide the controls
which might be problematic to some users as in mobile there is the
controls display but also an ugly "Tap to unmute" in the middle of
the video.
Step to reproduce (background video):
- Drag & drop a "Text - Image" snippet and add it the biggest possible
padding, also add padding to the image (so you see the full video and
not just part of it)
- Double click on the image, then on the video tab insert a vimeo url
- Save, you will see the controls for a few seconds (progress bar, video
title, link to vimeo, etc)
Step to reproduce (non background video):
- Drag & drop a "Text - Image" snippet and double click on the image
- On the video tab, insert a vimeo url
- Select "Auto Play"
- Save and go to mobile, you will see the controls and an ugly "Tap to
mute" in the middle of the video.
The "Tap to mute" is a browser feature, not a vimeo feature. Browsers
are muting video by default when auto play.
Still, some people want to have a nice auto play video shown to users
without sounds and don't want that overlay/controls.
opw-2901256
closesodoo/odoo#96804
X-original-commit: 7128e4080511b5f224da3dce6d88ba8bcf9a0d47
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Reproduction:
1. Install Inventory and Sales, enable customer address in the setting
of Sale
2. Create a quotation, choose a customer which has different contact
address and delivery address, add a storable product.
3. Confirm the order and click the delivery in the status bar
4. Click print->delivery slip, the Customer Address and Delivery Address
are the same
Reason: The Customer Address isn’t correct in the template
Fix: replace the partner setting in the customer address part as either
the partner or its parent partner_id, e.g. the commercial_partner_id
opw-2851158
closesodoo/odoo#96800
X-original-commit: 500687e45e83a8bf7c4ab31e659c7eb9dc83aa4c
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Liu Jinjiu (jili) <jili@odoo.com>
Pillow 9.1 deprecates most if not all toplevel Image constants:
https://pillow.readthedocs.io/en/stable/releasenotes/9.1.0.html#constants
These constants have been moved to thematic enum classes (e.g. all the
resampling constants in `PIL.Image.Resampling`).
This triggers warnings in Odoo, and the removal delay is quite short
(slated for Pillow 10, release planned mid 2023). Pillow 9.1 is also
already in Debian Bookworm (current testing).
Fix by shimming at the import level: if the enums are available import
them into the local namespace, otherwise alias `PIL.Image` itself as
to the enum.
closesodoo/odoo#96799
X-original-commit: 7be04d31bad078681ef0a2919234c11840a2e8e2
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit:
On pasting image to editor, the default width was set to auto.
After this commit:
Now on pasting image to editor, the default width is set to 100%.
Task-2862892
closesodoo/odoo#96779
X-original-commit: 2e4811b751960548dc66f6e4ff00495e5226fdbc
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
*: website_livechat
This commit is a step towards refactoring the JS of public livechat,
so that it reuses the same architecture as the code of Discuss.
This implies code that uses JS models and OWL components.
Task-2928837
closesodoo/odoo#96690
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This nomenclature was taken straight from the old Summernote options
when the new editor was merged in 15.0.
While perfectly correct from a technical point of view, the use of the
word "Auto" in this context is confusing because the user might think
that the system is going to choose an optimal size for them while this
is not what this option does at all. What it does is simply removing any
width style property that might be set on the image, thus letting the
image be sized appropriately by the browser in accordance with active
CSS rules at that position in the page, hence its "Default" width.
closesodoo/odoo#96679
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
It now uses the new owl code, instead of the legacy list view, which
will be removed in the future.
closesodoo/odoo#96595
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Purpose
=======
Show a help message in the "mail gateway allowed" list view that
explains why this model is useful and what the email limit is.
Remove the normalized email from the list view and rename the label of
the email field.
Task-2885455
closesodoo/odoo#96588
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Without this the payment line amount is overridden before the request
is made to Mercury.
When a Mercury payment method is clicked a payment line with the right
amount is created. When a card is swiped it types a sequence like:
%B999000090000009^TEST...
The "typed" numbers are immediately interpreted by NumberBuffer and
will result in the payment line amount being updated to something like
9990000.... When the "barcode" is finished credit_code_transaction()
in pos_mercury will do the request using the amount from the
payment line (swipe_pending_line.get_amount()).
As a result a request is made to Mercury with a huge amount which
results in an error: "Error 1000211: Invalid Field - Purchase Amount".
Luckily NumberBuffer already supports barcodes, so the problem can be
solved by setting useWithBarcode. A small method was extracted to
override this cleanly.
opw-2892608
closesodoo/odoo#96392
X-original-commit: 49df357a3b897bc06aa5978c4b77c4cfda29070c
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Masereel Pierre <pim@odoo.com>
A field input always asks for a record update when it is the target of
a "change" event but such an event might occur after some keyboard
events (e.g. a "Enter"). In order to make keyboard navigation work, it
is necessary to make a dirty field communicate its new value before a
change event and make sure the record is correctly updated before being
saved.
Before this commit, this was done via a system based on a special event
triggered on the model each time a record is saved but that solution was
not appropriate:
- the updates done in that way were not correctly awaited.
- they would be asked for even if the save would not be the result of
a keyboard event.
Here we replace the old system by a simpler one that works. When some
specific keyboard events occur, a dirty field ask for an update that is
correctly awaited.
closesodoo/odoo#96101
Related: odoo/enterprise#29873
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit removes most of the calls to checkValidity outside of the
(Basic)RelationalModel.
The validity checks in ListRenderer were not useful
because the operations done after them (like a switchMode) would make
a validitity check and the expected goal would be achieve in any case.
Part-of: odoo/odoo#96101
When rewriting the Form view, we wanted the keyboard navigation using
"tab" and "shift+tab" to use the native browser behaviour. The purpose
of this commit is to remove the custom behaviour of X2many in a
form view when a "tab" or "shift-tab" make it be focused.
Before this commit, a new empty line would be created automatically.
After this commit, the button "Add a line" takes focus but no new line
is created.
If one wants to add one, that can be done by pressing "Enter".
Part-of: odoo/odoo#96101
In this commit, we improve some tests by making them use the util
function "editInput". Indeed those tests were incorrectly reflecting
the edition of an input: normally, change the value of an input should
trigger an "input" event.
Part-of: odoo/odoo#96101
Before this commit, in an X2many in editable list mode with a handle
field, if you passed a record in edit mode, the handle field was focused.
The expected behaviour is to focus the first editable field.
Part-of: odoo/odoo#96101
Before this commit, in an X2many in editable list mode, creating two
valid records in succession by pressing Enter caused the first record
in the list to go into edit mode. The expected behavior is to add a new
empty line.
How to reproduce:
- Create a first valid record
- Press the enter key to validate it and a new line is created
- Complete this new line in a valid way
- Press the enter key to validate it
Result before the commit:
The first record switched to edit mode and there is no new empty line.
Result after this commit:
A new blank line is created in edit mode.
If you press enter again the empty line is validated and a new line is
created.
Part-of: odoo/odoo#96101
Before this commit, in an x2many in list mode, it was possible to switch
several records to edit mode.
Normally, it is not possible to have more than one record in edit mode
in a list mode X2many.
How to reproduce:
- Have an X2many with at least two record already.
- Modify a field of the first line and make it invalid
- Click on the second record
Result before the commit:
Both records will be in edit mode.
Result after the commit:
The invalid record stays in edit mode and the other record stays in
readonly mode.
Part-of: odoo/odoo#96101
When you are eon the details form of partner in POS UI, you have a
button 'More Info' that redirect you to the backend partner form. This
button is always displayed and can lead to a traceback if you are
clikcing on it while creating a new partner.
To avoid such issues, we are only display the button when we are
editing existing partners
closesodoo/odoo#92967
Signed-off-by: Masereel Pierre <pim@odoo.com>
In the customer list, the partner email and phone number are displayed,
but if the partner has a mobile number, it is not displayed and also not
editable in the details.
We have added the possibility to register the mobile number directly
from POS interface, and we display it in the list of partners if it set.
Task-id: 2817067
Part-of: odoo/odoo#92967
Steps to reproduce:
- Install Studio, Contacts, l10n_in
- Go to Contacts, open studio on the form view
- Edit the GST Treatment field name
-> No changes are made
Cause of the issue:
When combinings views to generate the final arch, extensions are
ordered by priority. Studio edits have a priority of 99 but in this
case, there is an override with a priority of 100.
opw-2899654
closesodoo/odoo#96713
X-original-commit: b97daa993347acd763c080eb8f5f4157a3359ab8
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Steps to reproduce:
- Install accounting module
- Ensure there is 2 companies
- Activate both companies (with company switcher)
- Go to Accounting -> Configuration -> Currencies
- Select currency `EUR`
- Add a rate and set second company as company
- Disable second company (with company switcher)
- Click on `Show Currency Rates` in action menu
- Click on create
Issue:
Access Error
Cause:
Currency Rate model have a compute field `rate`.
This last one calls `_get_latest_rate` that will retrieve the last
rate for the currency. To do so, it will first retrieve all rates for
the currency (that might include rates with company not same as the
current one) before fitering regarding company.
Solution:
Use sudo(). Same issue/fix for `_get_last_rates_for_companies`.
opw-2832708
closesodoo/odoo#96714
X-original-commit: dda5c9084b9913968e67c8b280de870c81227e16
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Impacted versions:
- 15.0
Problem A) Date not showing at proforma at newly opened orders.
Steps to reproduce:
1) Enter Point of Sale module
2) Configure a PoS as a Bar/Restauran with Bill Printing before payment (with or without Floor and Tables).
3) Start a new session in the configured PoS.
4) If Floors and Tables is configured, select a Table. Otherwise skip
this step.
5) Add some products to the order.
6) Push the Bill Button.
7) A bill ticket will appear at screen.
Current behavior:
In the bottom part of the bill the date is not showing at its place
between Order Reference and PRO FORMA text.
Expected behavior:
Date should be shown after Order Reference at the PRO FORMA bill.
Problem B) Date showed at proforma with different timezone (more/less
hours).
Steps to reproduce:
1-5) Same steps as Problem A) but Floor and Tables configuration must be
active.
6) Push the top green button to return to Tables screen (or wait one
minute).
7) Return to the same Table with recently created order.
8) Puss the Bill Button.
9) A bill ticket will appear at screen.
Current behavior:
The date in the bottom part of the PRO FORMA ticket is showing a time
with a different timezone (with more or less hours). Besides, the time
printing correspond to the time where the order was saved, not the
current time of printing the bill.
Expected behavior:
Date must show the correct time accordingly to the actual timezone and
to the moment of printing the PRO FORMA bill.
Video/Screenshot link (optional):
https://youtu.be/-2Td-RjhR9Uclosesodoo/odoo#96776
X-original-commit: 0ca6e48b3662432dfb128ed8d6625cd598ca5e32
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
In the `write` method, accessing the `ms_organizer_event_id` field of
`self` leads to an exception if `self` represents several records.
So, the idea of this fix is to set the `need_sync_m` field of all modified
records to `True` when at least a field to sync with Outlook is modified
(see `_get_microsoft_synced_fields()`) and then, at the end of the `write`
method, really patch or delete records that are already linked to Outlook
(that means they already have their `ms_organizer_event_id` field set).
closesodoo/odoo#96761
X-original-commit: 1a66343327f9ea9f59ba25ea63e26331cabb65b5
Signed-off-by: Arnaud Joset <arj@odoo.com>
Previously, attempting to add a class to a button box would crash
because the button box divs are compiled to ButtonBox component which
did not accept a class prop. This commit fixes that.
closesodoo/odoo#96726
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: im_livechat, snailmail_account, survey, web_editor.
The callback registered by the bus service method onNotification was
not the same unregistered by offNotification. Since those method were
superfluous, they have been removed in favor of (add/remove)EventListener.
closesodoo/odoo#96684
Related: odoo/enterprise#29819
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Lucas Perais