Before this commit if Identify Customer option was enabled for a
payment method in point of sale but no customer was set for an order,
we get a SQL constraint error that has no hints on where the problem
comes from.
This process can be improved by a better error message that directly
points out the problem.
opw-2907152
closesodoo/odoo#97566
X-original-commit: 06c8765d362f81aa92f25029cb5d4e9d4069b3d3
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
The cumulative option on line chart is useful for displaying
cumulative information graphically.
closesodoo/odoo#97394
Task-id: 2146487
Signed-off-by: FrancoisGe <fge@odoo.com>
With the conversion to the new views, legacy x2many fields go through a
thin and incomplete compatibility layer to talk to the new model. This
compatibility layer is not very robust and as such most custom x2many
fields are broken in this configuration, in this case the field
"question_page_one2many".
The proper fix is to convert this field widget, but in the mean time,
the simple fix is to force this view to keep using the legacy view
instead of the new view.
closesodoo/odoo#97868
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Reproduction:
1. Install Website and eLearning
2. Add new language Dutch
3. Modify the course responsible’s name as “Gertjan Kleinbloesem” in
eLearning
4. Open the course page in the website app and switch to Dutch, the
responsible name is over flowed
Reason: The background container doesn’t adapt to the length of the text
Fix: Add text break to the responsible's name so it won't break the
style
opw-2862250
closesodoo/odoo#97839
X-original-commit: bb2045f77ee7383af85b2d65c015d91f92b20647
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Liu Jinjiu (jili) <jili@odoo.com>
The Powerbox crashed whenever a command was wrongly defined. That's a
bit too brutal so this sets defaults instead.
closesodoo/odoo#97794
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
pull-right is not standard Bootstrap 3.
closesodoo/odoo#97851
X-original-commit: 1098377b4e8fff4400c03da405903d9ba246dbd8
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Only for terms containing Credit Note and expenses
closesodoo/odoo#97840
X-original-commit: 1754b094a66476a0bdb29fe60dc5583c03336c3f
Related: odoo/enterprise#30262
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When you print or preview an invoice, the lines with the product are not
displayed. Before changes made in PR: https://github.com/odoo/odoo/pull/96134
the lines containing products didin't have a display_type.
Since those recent changes, their type is product, so we are now
checking that they are of display_type 'prodcuct' instead of having the
display_type to false
closesodoo/odoo#97862
Signed-off-by: Masereel Pierre <pim@odoo.com>
Using named attribute 'start' in sum function is not compatible with
python 3.7, it is also set as 'start=0' which is useless as it is the
default value of start argument.
Part-of: odoo/odoo#97862
Steps to reproduce:
- Switch language to french
- Refresh the page
- Create a new payment
- Select a partner
- Enter an amount of 100000,00
- Save the record
-> The following field is incorrect: amount
Cause of the issue:
Since https://github.com/odoo/odoo/pull/97425 ,
`parseMonetary` wrongly assumed that a currency was always passed in
the parameters
opw-2937403
closesodoo/odoo#97861
X-original-commit: 9d518f847d2204fc5159a92bc4e4de655acf88fa
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Fixup for 4caa9596bc, where a rebase went bad.
Have a translatable field in a form view.
Create a new record with that form view.
Click on the button to open translations for that field.
Before this commit, the record was not before opening the translation dialog, hence
changing the translations could not work properly.
After this commit, this feature is back, and we ask to save a new record before
opening the translation dialog.
closesodoo/odoo#97824
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Issue:
Customers can use Mollie and lower the price on a quotation through changing the
delivery method, if they have two pages "/shop/payment" and proceed with payment
on one they can still change the carrier on the second. Although the quotation is
not confirmed because of mismatching amount, a confirmation email is still sent
and a bank payment is still created. Please see the following test video.
Solution:
We add a check so that changing a carrier can only be done when a no active/done
transaction is linked to the sale order.
opw-2925673
closesodoo/odoo#97818
X-original-commit: 151edb7d088ec9e5ea10fa8f184c7cb3a030a6ab
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Oversight of: 129b91027700313066db0305876adcf9b2a3817d
If the view is not up to date, it will not display any agenda locations.
We need to keep the 'locations' key into the returned values for code
retro-compatibility.
Task-2942630
closesodoo/odoo#97751
X-original-commit: 6c72297e72e0936e5564f175dcb1716057e0ac4b
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Since [1] when the search bar was refactored, a search facility was
added on website pages and the rendering of those search results did
not correctly handle the HTML escaping.
This is related to the fact that the `ir_ui_view`'s `arch_db` field is
stored with this double escaping on text nodes, which is done by
`wysiwyg.js` through the `_getEscapedElement` method since [2].
This commit unescapes the last layer of `&` before extracting the
page's text for generating the search results.
Steps to reproduce:
- Add some "&", "<" or ">" characters in a page.
- Use the search snippet to lookup for the page.
=> The results in both autocomplete and the results pages display the
content with an extra unwanted escaping (&...)
[1]: https://github.com/odoo/odoo/commit/9f9c4bb7e40233e633f97c60fb00ae191e9077af
[2]: https://github.com/odoo/odoo/commit/f5acea7f9ce232773ec3adf1828a3d18bbedee1e
opw-2908645
closesodoo/odoo#97748
X-original-commit: 2b95dcdb0d8b49bac8ee38a8d062112468124012
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Since removing the "Styles" option and the CSS that went with it,
there is an issue with the center alignment on icons.
Indeed, having a fixed width/height value on `fa.rounded` allowed the
icon to be centered along with its background.
By removing the fixed with/height values, the center alignment
(using `.mx-auto` and `.d-block`) would center the icon but stretch the
background color to the full width of the parent.
To achieve the same result, the cheat is to set the
default value of the wrapping block to text-center and remove
`.mx-auto` and `.d-block`.
closesodoo/odoo#95974
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This theme was using a static image which was designed in a triangle
shape but could not be edited with the `Shapes` option.
In order for the user to be able to change the shape of this image,
much like in the previous commit, a square version of the image is used
as an `original-src`, and the triangle version of it is used as `src`
in the theme.
task-2836942
Part-of: odoo/odoo#95974
As mentioned in the previous commit, the circle in the `Styles` option
has been replaced by a shape.
Previously we used `.rounded-circle` on images to make them round,
now we use the new circle shape from the `Shapes` option to achieve
the same effect.
This change has been applied on the snippets' images.
Snippets containing icons with these options have also been modified.
In the builder, the `Shapes` option generates a second image (circle)
from an original source (square image) and applies various
data-attributes.
In order for the option to function correctly on snippets,
the different data-attributes such as `data-original-src` and
`data-shape` have been added manually to the snippet's images.
This creates a need for an original image and a shaped version of the
image in the repo.
task-2836942
Part-of: odoo/odoo#95974
The `Styles` option contains styles which are unsupported in
emails. The few that are supported can be replaced by other options.
- Shadows: unsupported;
- Rounded rectangle: (unsupported in Outlook)
is replaced by the `Border` options which allows to customize the
border's radius more than the current option.
- Thumbnail: can be done with a combination of `Border` and `Padding`
- Circle: can be done with a shape
(which has been added along with other new shapes)
This option could be found on images and icons and has now been removed.
CSS styles in the `theme_default` file have also been removed since
they are no longer needed.
Three basic shapes (circle, triangle, "slanted" rectangle) have been
added to the `web_editor`'s `Basics` shapes page.
A condition was previously set on the page to avoid showing an empty
page. The condition is moved to each of its buttons instead, so that
new shapes added via xpath from `mass_mailing` to this page are now
visible.
task-2836942
Part-of: odoo/odoo#95974
Before this commit, the tour test_image_upload_progress was failing
inconsistently at the step "check that the file was correctly uploaded"
during the upload of a single image.
[1] adapted the upload progress toast to owl, but it used a state
variable isVisible, updated with a useEffect hook called on change of
the file props. This was not optimal: the visibility could be updated
directly through a reactive variable from the upload service. Instead of
automanaging its visibility, the component is completely driven by the
upload service.
This small optimization is useful in regards of the implementation of
the TourService.
As it is implemented now, the TourService works this way:
When it completed a step, it will check for the tooltip of the next
step, in the next javascript call stack.
If it does not find it in the DOM at that time, it will listen to the
mutations and wait for 750ms after the last one to check again.
Here, as the progress toast was rendered visible not directly when
uploading a file, but after another render, after the useEffect was
executed, the progress toast was sometimes not found directly after
playing the step sending the 'change' event. Then, the TourService was
waiting for all the mutations to execute (the progress toast appears,
the media dialog closes itself, the toast hides itself) and check again
after a delay. But by then the toast was already hidden.
With that, the tour steps are rewritten to follow the flow:
- Open the media dialog in single upload mode
- Upload an image
- The toast is shown
- The media dialog is closed
- The toast with "The file has been uploaded" is still there
- The toast autohides
Also, the file input value is reset after uploading files, otherwise it
was not possible to upload the same file twice (the 'change' event was
not triggered).
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
runbot-4117
closesodoo/odoo#95890
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The tour .test_03_backend_dashboard was failing inconsistently with a
"failed to fetch" error (which happens when fetching the frontend
assets, from the iframe).
The test is adapted to start directly in the backend, which seems to
prevent that error from happening.
It is also adapted to [1] which was merged during the investigation of
that error.
[1]: https://github.com/odoo/odoo/commit/985e49bdb5e22fa197ba267aa41d7a8ba7e50550
runbot-4418
runbot-4003
Part-of: odoo/odoo#95890
An error occurs when importing the Italian edi xml it the partner bank
account number is defined and the database is configured in such a way
that one partner has multiple res.partner.bank records, with the same
acc_number. This is possible in V14, since the constraint is:
'unique(sanitized_acc_number, company_id)'
meaning that the same bank account on the same partner can occur
multiple times (with different company_ids).
Since the domain of the search performed in the import function didn't
specify the company id or a limit, upon assigning the partner_bank_id
with the values from the search, an expected singleton error occurs.
This has been solved by altering the search domain to include only
partner bank accounts where the company id matches that of the invoice
or where the company id is None (which is technically possible, though
unlikely). A limit of one has been added to the search, and the results
are ordered by company_id, which will result in the res.partner.bank
with a company_id being selected before the one with no id.
This relates to a ticket:
closesodoo/odoo#92881
Task-id: 2854284
X-original-commit: 8cf535a240dea12a5a8b1e0ef3b5b82698379bf1
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
*: microsoft_outlook, website_twitter
Steps to reproduce:
- install the google_gmail, microsoft_outlook and website_twitter
modules
- go to Settings > General settings > Discuss > External email servers
- for the twitter module go to Settings > Website > Features > Twitter
roller
- the client secret fields are visible
This commit changes the fields types into 'password'.
opw-2936506
closesodoo/odoo#97722
X-original-commit: 18a792ee21441a2e07cef5997368e6d1a268f46c
Signed-off-by: Anh Thao PHAM <pta@odoo.com>
Signed-off-by: stcc-odoo <stcc@odoo.com>
This old file is indented with tabs instead of spaces.
This is a problem because the file is using as template to
write new localization.
closesodoo/odoo#97718
X-original-commit: abedeb1fe4705c8e4d36cf7f9d61c61ca2b924dd
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Before this commit, it was impossible to correctly save a record
containing an invisible required field in its template.
Problem:
When a record tries to be saved or switched to readonly, it will check
the validity of all its fields and if any of them are invalid, it will
cancel the save or switch to readonly. In our case, we have an invisible
required field. If this field is invalid, it is impossible for the user
to modify it because it is invisible. So he cannot make it valid. So it
is not possible to save this record or to switch it to readonly mode.
Solution:
We no longer check the validity of invisible fields.
How to reproduce:
- Go into a list view with a template containing a field that is
invisible and required
- Click on Create
- Click on Save after editing the record
Before this commit:
The record doesn't save itself and doesn't go into readonly mode
After this commit:
The record is saved and in readonly mode
We have the same problem in the form view.
closesodoo/odoo#97610
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Fix a typo in a default / field name for SMS composer.
Task-2613245 (Server actions mail update / cleaning
closesodoo/odoo#97757
X-original-commit: 835c68e574ebae5980f57c53dc3c9fd1cd1707c1
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, the product_tmpl_id field was present in the
product_pricelist_view but not the product_pricelist_view_inherit.
This changes allows to have a simple solution to modify the product_tmpl_id attributes
in other modules.
closesodoo/odoo#97721
Taskid: 2886054
X-original-commit: 312107060f1b6d7aaa907792ee18c9ef22a47cd9
Related: odoo/enterprise#30211
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Arnaud Joset <arj@odoo.com>
Have a field with widget text_emojis.
Click Edit on the form view.
Click Save.
Before this commit, the button that opens the dropdown was still present in the dom in readonly mode.
After this commit, it is correctly removed.
closesodoo/odoo#97704
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, If "Show public price & discount to the customer"
discount display policy is selected, taxed prices in the pricelist with
discounts are compared with untaxed prices in the public pricelist,
which leads to not showing the discounted values when the pricelist
value is less than untaxed list price, but the taxed value is more than
untaxed list price.
Steps to reproduce:
1. Create a product, add it to a pricelist with a lower price in a way
that if the tax is added the price is more than its sale price, add a
tax option to the product
2. Set the pricelist discount display policy as `Show public price &
discount to the customer`
3. Set the PoS to use tax-included prices, and to use the discounted
pricelist
4. start the PoS session, add the product, you will see that the
public price isn't shown (with a strike-through)
To fix, we can use a different function that computes the taxed public
price, so it could be compared with the pricelist price.
opw-2919734
closesodoo/odoo#97698
X-original-commit: bbada7911ab59ca20c97fd152112116cab0bf398
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit, in a touch device the behaviour was a
"tap-hold-to-show” which let the user see the Tooltip by pressing the
element, and letting it disappear when the pressure ends.
This commit allows choosing between the previous "tap-hold-to-show"
behaviour and a new "tap-to-show" which let the user see the Tooltip by
pressing the element, and keep it open until it press something else.
This behaviour is more adapted when the tooltip is on a specific icon,
as is the case for the labels, since : f981c5f8f0closesodoo/odoo#97680
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Have a translatable field in a form view.
Create a new record with that form view.
Click on the button to open translations for that field.
Before this commit, the record was not saved before opening the translation dialog, hence
changing the translations could not work properly.
After this commit, this feature is back, and we ask to save a new record before
opening the translation dialog.
closesodoo/odoo#97608
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, images' url where just built upon the record's id and model.
Since the browser caches GET requests by url, the same record would always have the same image url.
Hence it appeared that when changing a record's image in form view, and going back
to the kanban, the image displayed was the old one.
A good enough approximation to solve this (and was actually solved in legacy code), is to use
the record's __last_update field, which basically tells the browser to re-fetch
a record's image when then record go through any modification.
After this commit, images are correctly updated in kanban and form views.
closesodoo/odoo#97544
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
When a session is opened, the setting that allow using pricelist cannot
be modified, as it can change the prices that should be used, but
existing opened POS will still use the old one.
As the pos settings are now in the res config settings, each time a
setting is changed, all settings are re-written. As the use pricelist
setting is not readonly when a session is open, its value is sent, and
we try two write it (even if value not changed) and it trigger a
constraint saying it cannot be modified.
To avoid such a wrong behavior, we make it readonly when it cannot be
modified.
closesodoo/odoo#97731
Signed-off-by: Masereel Pierre <pim@odoo.com>
Before this commit, the `BlockUI` component
would not appear when printing a Sales Report
from the PoS backend.
To reproduce, go to PoS:
-> Reporting
-> Sales Details
-> click Print
Issue: The `BlockUI` component should appear on
top of the `Dialog` component, but it doesn't.
The reason for this is because, after some recent changes,
the z-index of 1100 that this component initially had, was
no longer applied, resulting at a lower z-index value for
the `BlockUI`.
In this commit we restore the normal behaviour.
task-2924335
closesodoo/odoo#97730
X-original-commit: 114fbe04eb92248118af46c8cbd137da7233aef9
Signed-off-by: Masereel Pierre <pim@odoo.com>
Before this commit, the `BlockUI` component from
the web module was not rendered properly.
The reason for this is that after PR #83811 was merged,
the css from `web/static/src/core/ui/block_ui.scss`
was replaced with non-semantic Bootstrap css classes
(e.g. .d-flex, .justify-content-center). Those css
classes were inaccessible to PoS frontend, because
the `point_of_sale` module does not load Bootstrap
code (a design decision).
In this commit, we restore the proper rendering
of the `BlockUI` component both for the "frontend"
of the PoS App.
task-2924335
X-original-commit: 29cbeae90790ff503167b053ec6d9e221a82434e
Part-of: odoo/odoo#97730
The constructor of OdooEditor called a function that initialized the
Powerbox. This moves that function inline into the constructor to avoid
a function called only once, and moves the main commands and categories
directly into the arguments to `new Powerbox()`.
closesodoo/odoo#97725
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The BusService class only adds the possibilty to send notifications.
This is only used in the mail module. Let's remove this unnecessary
override and move this functionnality into mail models.
closesodoo/odoo#97685
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Running tests for `project` module only fails with the following error:
```
2022-08-02 08:19:41,777 5669 ERROR testdb odoo.addons.project.tests.test_project_report: FAIL: TestProjectReport.test_avg_rating_measure
Traceback (most recent call last):
File "/build/odoo/saas-15.3/addons/project/tests/test_project_report.py", line 22, in test_avg_rating_measure
self.assertEqual(self.task_1.rating_last_value, 5.0)
AssertionError: 4.0 != 5.0
```
With the ORM flush mechanisms when multiple ratings are created at once
they all have the same `create_date` and/or `write_date`, this commit
ensure the order is deterministic.
closesodoo/odoo#97691
X-original-commit: 567d27cc600bdbb39d62e7aa75b37d48b33d27a5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The default order of the picking moves generated from a sale order should be the same order as the sale order lines.
Steps to reproduce:
- Create a sale order with several sale lines.
- Change the order of the sale lines.
- Confirm the sale order.
=> The moves of the picking don't maintain same order as set before.
closesodoo/odoo#97690
X-original-commit: 524e5e6bd8feb47256cc0941052d959dd0e0ad0c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In order to perform reverse charge self-invoicing, a company must have
its codice destinario (pa index) defined. This commit adds a valid
pa_index (from the sdicoop test channel) to the demo company.
closesodoo/odoo#97658
X-original-commit: 42c08b298dba5d4e34ed10ae4fd8828db9636a8a
Signed-off-by: Josse Colpaert <jco@odoo.com>
For performance reasons, when fuzzy search was introduces it was
decided to limit the number of records used for finding fuzzy terms to
1000. Because of this, when a database contains more than 1000
products matching words that start with the same letter, further
products are not examined. This can lead to searches not finding an
existing exact match.
This commit introduces a fallback mechanism so that, if we are in a
situation where the maximum number of examined records was fetched, we
also explicitly check for a possible exact match across all records.
Steps to reproduce:
- Do not install the pg_trgm extension.
- Have more than 1000 products containing searchable words (name,
description...) starting with the same letter.
- Add one more such product (so that it is not in the 1000 first ones).
- Search for that last product by correctly typing the word.
=> Exact match was not returned.
task-2870947
closesodoo/odoo#97657
X-original-commit: 6d24ea28b236155d542e3d2be3da379b9f4e9ce6
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Ahmad Khanalizadeh