Steps to reproduce:
- in A1, type '02/2024'
- in A2, type '=ODOO.BALANCE("100", A1)'
=> the result you get come from account lines
for the day 2024/02/1 instead of the full
february month.
The value of A1 is detected as a number (first of february 2024)
When that number is given as the argument of ODOO.BALANCE,
the number falls back as being interpreted as a single day,
instead of a month period.
opw-3872445
closesodoo/odoo#163156
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This commit actually refactors the code of the accounting functions
to use `computeValueAndFormat` instead of `compute` which doesn't
receive the arguments format.
The goal is to make the actual fix in the next commit easier
to review/understant with minimal noise.
opw-3872445
Part-of: odoo/odoo#163156
Steps to reproduce:
- in A1, type '02/2024'
- in A2, type '=ODOO.BALANCE("100", A1)'
- right click on A2
- click the menu item "See record"
=> you end up with wrong records in the list view
The value of A1 is detected as a number (first of february 2024)
When that number is given as the argument of ODOO.BALANCE,
the number falls back as being interpreted as a single day,
instead of a month period.
opw-3872445
Part-of: odoo/odoo#163156
Steps:
------
1. Have accounting installed.
2. Have a bank journal with a currency different from company's currency,
use a bank account with no currency set for this bank journal.
3. Make a misc operation in the bank account used by the journal.
4. On the dashboard, the "Misc. Operations" amount will not be converted
to the journal's currency, even though the currency's symbol is correct,
the amount is in the company's currency.
Fix
---
Do not show the total amount of misc operations if the bank journal and
bank journal's bank account currencies are not matching. The user still
knows there are journal entries not linked to a bank transaction thanks
to the "misc operations" text, but we avoid doing a currency conversion
that may not make sense.
opw-3767010
closesodoo/odoo#156655
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Steps to reproduce:
-------------------
- create a product tag (eCommerce / Product Tags);
- go to a product page and open editor;
- edit the page adding a "Products" block;
- add the created product tag;
- remove it and save;
Issue:
------
No products are displayed, whereas without tags,
a default product set should be displayed.
Cause:
------
At first, when we don't have a tag, the domain determined
for the search is `[]`, which returns a list of products.
When we add the tag, a domain will be built with the products
linked to this tag: `['all_product_tag_ids, 'in', []]`
(in the case of the use case above, there will be none).
The attribute `data-product-tag-ids="[]"` is added to
the dynamic snippet section.
Then, when we remove it, we will get the same domain:
because the string `"[]"` is valid for the condition
that checks whether `productTagIds` exists.
As a result, it will no longer be possible to obtain
the default set for this block.
Solution:
---------
Try to reduce the domain to a list in all cases and compare its length.
If it is empty, the domain must be an empty domain.
opw-3859482
closesodoo/odoo#163324
X-original-commit: c18ab6acf63885401a3e702f912622369197bdf7
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Steps to Reproduce
------------------
1. Install `sale_management` and `account_edi`.
2. Create a user with admin access in sales but no rights in accounting.
3. Log in as the new user.
4. Navigate to a Sales Order that has been invoiced and attempt to view
its invoice via the 'Invoices' stat button.
Expected Behavior: The user should be able to view the invoice.
Actual Behavior: An access error is encountered when attempting to view
the invoice.
Cause
-----
The access error arises due to restricted permissions for
`account.edi.format` and `account.edi.document`. Prior to commit
604a47ead8, all users had access to these
models. However, this commit restricted access solely to users with the
`account.group_account_readonly` role, as part of a broader security
enhancement to minimize unnecessary access by portal users.
opw-3858685
closesodoo/odoo#163412
X-original-commit: 3be00fa01ed400c2bd7b4fda49871fd14869a48d
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
*: web, web_editor
Follow-up of [1] (see its own explanation for details).
This is about fixing the remaining code. In the future, we will probably
go even further:
- No more wrapwrap element at all
- No support of a main scroll which is not left up to the browser (see
some more details about that in [2] which explains the many problems
which occurred when the scroll was on the wrapwrap element).
Those final points have yet to be confirmed though.
All in all, this PR should not change any behavior in the standard
stable versions. But it will fix bugs in some custo trying to change the
page scrolling behavior, while unifying the versions codebases.
[1]: https://github.com/odoo/odoo/commit/ffc19547c8da2ef7fee8e2ac743ab99a607dcf90
[2]: https://github.com/odoo/odoo/pull/98429closesodoo/odoo#163393
X-original-commit: 10df96564fcadd6acde52adf8bf1da32990f3dcf
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_mass_mailing
Before this commit, when a "Form" snippet was added and the action was
changed to "Subscribe to Newsletter", the mailing lists appeared as
checkbox fields with the number of subscribers in parentheses. This
commit removes the display of this unnecessary information.
Steps to reproduce:
- Install the "Email Marketing" module and Website.
- Navigate to the Website in edit mode.
- Drag & drop the "Form" block (dynamic content section).
- Change the form action by setting the "Action" option to "Subscribe to
Newsletter".
Bug: The number of subscribers appears next to the mailing list names.
task-3472820
closesodoo/odoo#163336
X-original-commit: a060a1981074a83b77b28f70b49127ecb6f4f550
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Adrien Milis <miad@odoo.com>
The test_sudo_commands fails when testing portal user without demo data.
With this commit, a portal user is created in a setupClass.
closesodoo/odoo#163319
Build-error: 55927
X-original-commit: 83c2201543d4d37b2d8e760200c5b111e1d74fa1
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
This traceback arises when the user tries to remove the start date
Steps to produce
1. Install 'resource'
2. Open 'Settings/Technical/resource/Resource Time Off'
3. Create a new record and remove start date
AttributeError
'bool' object has no attribute 'tzinfo'
when the user tries to remove the start date, an error will be
produced because _compute_date_to seems to be computing the date_to
based on the date_from field. when removing the date_from from calculations
on empty or none
which leads to traceback from here
https://github.com/odoo/odoo/blob/322e7ea19b7c069fdb92d3b86e5615c55489ca21/addons/resource/models/resource_calendar_leaves.py#L54-L59
This commit solves the above issue by computing `date_to` for records that have
`date_from`. Apart from that, this commit also removes `# -*- coding: utf-8 -*-`
from the first line of the modified file.
sentry-4983497879
closesodoo/odoo#163311
X-original-commit: 5032a8ffed10bfbd619c85a266092f129716ceca
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Use an ir.config_parameters to set the period for the stock quantity report to
ease customization.
closesodoo/odoo#163266
X-original-commit: 86da6978bd683c4b67f7303138a3037af5c48328
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Nicolas Danhier (nda) <nda@odoo.com>
Current behavior:
If you make a sale of a product that use a taxe not included in the
price. Then go in order analysis in PoS, the total price of the product
will not include the taxes.
Steps to reproduce:
- Create a tax of 15% that is not included in price
- Create a product with 10$ price and add this tax to it. (Total price
including tax should be 11.5$)
- Sell it in the PoS and close the session
- Go in PoS > Reporting > Order. Open the pivot view and check the total
price for the product
- The total is 10$ instad of 11.5$
opw-3817535
closesodoo/odoo#163239
X-original-commit: 42fd6a65c8910bff587b6bc55d49e1bafb165487
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
The `test_update_workcenter_adapt_finish_date` test was not consistent
when the db was installed without demo data. The test was failing
because the working hours were not the same and so the duration was
different. To fix this we adjust the starting time of the work order
so that it last exactly 30 minutes, and is not impacted by the working
hours.
runbot error : https://runbot.odoo.com/web#id=61595&cids=1&menu_id=405&action=573&model=runbot.build.error&view_type=formclosesodoo/odoo#163238
X-original-commit: 5c49fc02f3fae0594b68d94bd8e9308bdbd21363
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Steps to reporduce:
1- Install Accounting, Fleet modules
2- Create a bill in accounting with a different currency than the company's default, and add a line with a chosen vehicle_id.
3- Go to the chosen vehicle in Fleet module
4- Navigate to the service created for this bill
Current behavior before PR:
If we create a bill for a vehicle using a different currency than
the company's default. The fleet service that will be created
will be having the company's currency but the value will be the amount
in the currency used in the bill
Desired behavior after PR is merged:
We now create the fleet service using the value in debit
not the unit price or the price subtotal.
opw-3734743
closesodoo/odoo#163228
X-original-commit: 0ef2abaa3e926daa71e004e0583503b7e3167a59
Related: odoo/enterprise#61408
Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>
Some options have been renammed a long time ago but there was no
mechanism to warn the user should those option be still present in its
configuration file.
Odoo versions up to Odoo 14 (excluded) used `osv_memory_time_limit` and
`geoip_database` in their configuration, those two options have been
renamed to `transient_age_limit` and `geoip_city_db` in 14.0 ab4000f and
saas-16.1 c59750d824 but no deprecation warning / automatic failover
were provided.
closesodoo/odoo#163193
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
The image displayed in the theme selection page is the last one that
was created out of the theme's manifest's `images` entry.
Because of this, when a theme has a different non-last image in a new
version compared to an old version, that image becomes the last created
one and is displayed in the theme selection page instead of the expected
screenshot image.
This commit preserves the order that was specified in the `images`
definition by re-creating all images instead of only the modified ones -
if an update is needed at all.
Steps to reproduce:
- Install `website` with a theme in 14.0.
- Upgrade to 15.0.
- Go to the theme selection page.
=> Some themes (e.g. `theme_beauty`) displayed their cover picture
instead of their screenshot.
task-2719425
closesodoo/odoo#163118
X-original-commit: 4bc165b68078638a8057c79162f428026ca81321
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
In order for preview images to be shown in the theme selection page, the
`update_theme_images` function needs to be called.
This was done in a `post_init_hook`, which is called e.g. when
installing `website`.
This was also done in a `website` override of
`ir.module.module.update_list()` which is called when updating a module
interactively.
Unfortunately, even though this override is defined, at the time
`update_list()` is called from `loading.py` when using `-u` in the
command line, the modules are not loaded yet, and therefore the override
is not applied.
Because of this, when a database was upgraded to versions that introduce
new themes or new screenshots for themes, `update_theme_images` was not
called during the upgrade, and the new images were missing in the
upgraded database.
This commit solves this by calling `update_theme_images` from a
`function` data record, so that it is run both on install and on update
of `website`.
Steps to reproduce:
- Install website and a theme in 14.0.
- Upgrade to 15.0.
- Access the theme selection page.
=> Images were missing for some themes.
task-2719425
X-original-commit: 8e73375e674ba0018ac4ea12a5b19bb4e6bcae31
Part-of: odoo/odoo#163118
Issue
-----
Users cannot create a new opportunity on the portal
if they don't have any.
Fix
-----
Apply the same change in 17.0 than 58356928dd9cf07158bca4e8c1ce0dcf5177d0b9
did in following versions.
opw-3809571
closesodoo/odoo#161870
Signed-off-by: Tanguy Quéguineur (taqu) <taqu@odoo.com>
Steps to reproduce:
- create-aprove-post an expense
- Go to the accounting dashboard
Issue:
expenses' amount is 0
Cause:
In `_count_results_and_sum_amounts`, since the expense.currency is the same as the company we don't get the correct result:
https://github.com/odoo/odoo/blob/d29a622740f6c34d25c52add5367bfdf58bbaf49/addons/account/models/account_journal_dashboard.py#L641-L644
Solution:
Get the right columns.
We also change the domain to make sure that expenses partially paid are also displayed.
Note:
For the test we check that even partially paid expenses are displayed. In Master we want the residual amount to be displayed.
In master:
Use the amount_residual (discussed with po Laura)
opw-3849036
closesodoo/odoo#162182
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Usecase to reproduce:
- Create a MO for 2 unit (1 component per finished product)
- Produce 3 units
- Mark as done
- Unlock and change the quantity to 3 units
Expected behavior:
3 components removed from stock
Current behavior:
6 components removed from stock
It happens because the set_quantity_done create a new stock.move.line
with excessive quantity. Then the write of qty_producing in
mrp.production will write this quantity on all the `stock.move.line`.
It results by moving number of sml * the new quantity producing
Solution do the write of new quantity done on the `stock.move` level
and let him manage the `stock.move.line`
closesodoo/odoo#161728
X-original-commit: fa3439e5c595a04e67fa22965d6b10bb1f487f63
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
If an order was validated in PoS but encountered a sync error, the
order would revert to a draft state and no receipt would be printed.
However, if an order was validated in PoS without internet, the receipt
could still be printed. When the internet connection was restored, the
system would attempt to validate the unsynced order. If a server error
occurred during this process, the system would try to revert the order
to a draft state and fail. This behavior is not ideal as an order with
a printed receipt should not be modified or changed. This commit
ensures that in the event of a sync failure, the saved orders do not
revert to a draft state.
opw-3858994
closesodoo/odoo#161250
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
The cover scss rule first stretches the image to fill the container completely,
then cropped at the size of the container.
This results in some poor display result if the image has a weird aspect ratio.
This is a behaviour change from saas-16.3 where the image wasn't cropped and
simply resized to fit inside the container.
opw-3826349
closesodoo/odoo#161111
X-original-commit: 0cc3a0edfcd68ebbd7930eedd2af82bd3b3a29fe
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Signed-off-by: Loïc Leloup (lole) <lole@odoo.com>
Some people want to manage the subcontractor stock the same way than a
classic stock. It will then impact the on hand value but it's the
behavior they want.
I keep the constraint on internal location since it will impact
valuation.
closesodoo/odoo#163262
X-original-commit: be8e1da9d9dc3b82479b1560c9d5e780c8ecb36b
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
When a DB is duplicated, it's going through the neutralize process
which is helpful to clean stuff that will be messing around with the
duplicated DB.
The CDN should actually be part of that. Since a CDN url is bound to a
domain, when you copy the database (and most likely run it on its own
different domain), it just won't properly work.
Indeed, if you setup a CDN X for domain A and then copy a DB to domain
B, this will happen:
- You access website B
- You try to load an img, which is using CDN X URL
- CDN X URL is fetching the ressource on DB A instead of DB B, which
might or might not exist (an image will likely share the same path so
it might work, but for assets url it might not if the bundle url has
changed)
In the event of the assets having changed, they will never be loaded and
the duplicated DB won't be loading properly.
The only workaround in this case is to switch to debug mode to bypass
the post processing and so the CDN url transform.
Useful commits:
- Introduction of neutralize
https://github.com/odoo/odoo/pull/67825
- Conversion of neutralize from ORM calls to raw SQL
https://github.com/odoo/odoo/commit/e5dbded9bb363351feff7ca8a56c7f8a6860f492
opw-3880102
closesodoo/odoo#163210
X-original-commit: ab6493ae9fff218a43df12829011a4f642902114
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
- Create an SO with an SOL and save the record.
** The `qty_delivered` of that SOL will be null in the DB. **
Cause of the issue:
Since the `qty_delivered` field is computed, the default value is set in
the DB comes from the `_compute_qty_delivered` method at record creation
However, no default value is set here when the `qty_delivered_method` is
not `'analytic'`.
Note:
In 15.0, a default value was set because of these lines:
https://github.com/odoo/odoo/blob/313418804ae5cb6a786488ffc174b8eebffb796e/addons/sale/models/sale_order_line.py#L350-L353
These were removed by this commit de4911a.
opw-3771589
closesodoo/odoo#163180
X-original-commit: 3e20e293771a252bbdcd395b5a12a2cef70f0218
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The survey.survey_user_input_rule_survey_user_read rule is
override in both hr_appraisal_survey and in hr_recruitment_survey.
The problem arises when both modules are installed. If so, the domain
is taken from the module that is installed the last.
This should not be case, instead domain should be combined.
On top of it, the domain is not corrected when the app is unistalled.
This commit fixes that too
task - 3597033
closesodoo/odoo#163138
X-original-commit: 5d4b5175855041efd6174fe5e35f06ede3b62818
Related: odoo/enterprise#61363
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Allow pos users to have the "internal note" button available even in
non-restaurant shops.
The changes also make sure that the button is disabled when there is no selected
orderline.
closesodoo/odoo#162863
Task-id: 3878947
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
This commit fixes an issue where the `sale_last_order_id` was not being
set in the session when the extra info step was added to the checkout
process. This caused an error during the validation of event payment in
`shop_payment_validate`.
Steps to reproduce the issue:
1. Install `website_event_sale` and set up a payment provider.
2. Add the extra info step to the checkout in the website.
3. Register for a paid event from the website.
4. Proceed to pay the order, which would previously result in an error.
opw-3864873
closesodoo/odoo#162657
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
Steps to reproduce:
- Install eCommerce
- Go to My account
Issues:
There is a box "Addresses" which is useless for the moment as it's
the same page that can be accessed by clicking on "Edit information".
The feature to have multiple addresses is going to be present in master at some point, however for now we're removing the box as it's useless.
opw-3869920
closesodoo/odoo#162626
Signed-off-by: Mattis Megevand (mmeg) <mmeg@odoo.com>
Steps to reproduce:
- Install e-Commerce
- Go to your portal into a quotation
- Go to the chatter and send an empty message
Issues:
A traceback is shown
Solution:
Catch the error and discard it as the parent method is already
displaying the error message to the user.
opw-3877096
closesodoo/odoo#162424
Signed-off-by: Mattis Megevand (mmeg) <mmeg@odoo.com>
Steps to reproduce:
- Activate "Analytic Accounting" in Accounting settings
- Switch to a mobile view
- Go to any view where there is the analytic distribution widget (e.g. expense form)
- Try to configure the analytic distribution
Issue:
When an analytic account is selected, it is not taken into account.
Cause:
In mobile view, a modal is opened with a kanban view to select the
analytic account.
Any click on this modal is closing the analytic distribution widget.
opw-3734050
closesodoo/odoo#162092
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Steps to reproduce:
- Create a product with 2 vendors
- Click replenish on the product page and select the second vendor
- The PO is created for the first vendor
Bug:
the replenishment will create a move which will create/edit a PO
the selected supplier is discarded
Fix:
set the partner on the procurement group to keep track of it
note:
'supplierinfo_name' no longer used, will be removed in master
related test ("test_procure_not_default_partner") is now irrelevant
opw-3776680
closesodoo/odoo#161974
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Found error during migration in customer database.
when company is archived but will get that company
on `self.env.company` of pos_config table,
this error is generated when it's try to create the
record for pos config from pos_resturant module
by data file (defined on this commit)
https://github.com/odoo/odoo/commit/3236c1cb5025d2c2d446d11f67fda1ea51ceb992
as picking_type_id field in pos_config is required
and we set default value by fetching warehouse for related company
but here as company is archived, related warehouse is also
archived and that why we didnot get picking_type_id
for archived company and that will raise Error :
```
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4787, in _create
cr.execute(SQL(
File "/home/odoo/src/odoo/17.0/odoo/sql_db.py", line 332, in execute
res = self._obj.execute(query, params)
psycopg2.errors.NotNullViolation: null value in column "picking_type_id" of relation "pos_config" violates not-null constraint
```
closesodoo/odoo#162590
X-original-commit: 34b9bf83eeba55c1e05a916064dafcc7a9d7356e
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Atul Patel (atp) <atp@odoo.com>
step to reproduce:
1. account journal with `INV` code AND
`FAC` translated code, will get
two journal which was raise traceback
as we have unique constraint raised.
these are two journal with 1. INV code
2. FAC code as translated code
so will get two journal and got traceback
```
select name,id, code from account_journal where id in (12,13);
name | id | code
----------------------------------------------------------------------+----+------
{"en_US": "Factures clients", "fr_BE": "Factures clients"} | 12 | FAC
{"en_US": "Factures fournisseurs", "fr_BE": "Factures fournisseurs"} | 13 | INV
(2 rows)
File "/tmp/tmpwqzy2fx8/migrations/account/saas~16.2.1.2/end-migrate.py", line 50, in migrate
ChartTemplate._pre_reload_data(company, template_data, data)
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 264, in _pre_reload_data
self.env['ir.model.data']._update_xmlids([{
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_model.py", line 2270, in _update_xmlids
rows.add((prefix, suffix, record._name, record.id, noupdate))
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 5142, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: account.journal(12, 13)
```
closesodoo/odoo#163185
X-original-commit: 32b4bd2e146522c3feb03e34d0e9bd3261e37cbe
Signed-off-by: Atul Patel (atp) <atp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
When the Manufacturing Order 'qty_produced' is different than the 'product_qty' (we produced more or less than expected), then unbuild order had the wrong quantity for the finished product, and if 'mo_id.qty_produced > mo_id.product_qty', then an extra confirmed move was generated upon the validation of the unbuild order.
OPW-3860612
closesodoo/odoo#163096
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Prior to this commit, the `form-range` track color used the light color.
This created a color inconsistency with the rest of the UI when we
changed the third color.
Steps to reproduce:
- Go to the Shop page.
- Click on Edit.
- Click on the page and make sure "Price Filter" is active in the Web
Editor.
- Go to Theme tab.
- Change color-3 (light) to another one (eg. red).
This commit adjusts the color to maintain consistency with the rest of
UI elements.
task-3702675
closesodoo/odoo#150886
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Prior to this commit, checkboxes, radios and switch inputs had a color
issue in frontend: as the inner element (eg. check mark) was always
white if the user changed the primary color to a bright one, the inputs
were no longer readable.
Steps to reproduce:
- Go to the Contact page.
- Click on Edit.
- Click on Theme tab.
- Replace the primary color with a bright one (ex. light gray).
- Click on the form in the page.
- Add a field.
- Select the new field and choose the "Radio Buttons" or " Checkbox"
type.
- Click on Save.
- Check the checkbox or the radio button.
=> The check mark or the dot is not visible enough.
This commit adjusts the colors to ensure that these inputs will always
be visible.
task-3702675
Part-of: odoo/odoo#150886
Prior to this commit, dropdown inputs had a color issue in frontend:
the caret color of `form-select` was dark regardless of the input's
background and didn't provide enough contrast when we defined a dark
background on the page.
Steps to reproduce:
- Go to the Contact page.
- Click on Edit.
- Click on Theme tab.
- Replace the fourth color with a dark one (ex. black).
- Click on the form in the page.
- Add a field.
- Select the new field and choose the "Selection" type.
- Click on Save.
=> The dropdown caret is not enough visible.
This commit adjusts the caret color to make sure that this will be
always visible.
task-3702675
Part-of: odoo/odoo#150886
=== Maintain border consistency of frontend inputs ===
Prior to this commit, `form-select` borders overlapped the background
color, which is not the case with `form-control`.
This is because `form-control` uses the `background-clip` property.
As we're using a semi-transparent border on frontend inputs, this
creates a color issue: when a `form-select` input is disabled, the
border color is darker than that of the `form-control`.
This commit adapts the `background-clip` on `form-select` input to
maintain color consistency between inputs.
=== Make disabled inputs more recognizable ===
Prior to this commit, disabled inputs were not sufficiently distinct
from regular inputs, especially `website_sale` inputs which had a gray
background.
Steps to reproduce:
- Make sure your instance has website_sale_renting installed.
- Go to the Shop page.
- Look for a product with a rental period (eg. Printer).
- Click on Add to cart, this will disable the rental period input.
=> The gray search bar and the disabled input have almost the same style
This commit adapts the style of disabled inputs in the frontend to make
them more recognizable.
task-3702675
Part-of: odoo/odoo#150886
Prior to this commit, the custom dropdown caret in the `website_sale`
sidebar didn't handle the "multiple" attribute,
unlike the default dropdown.
If we decided to add a "multiple" attribute to this element, the caret
remained displayed, which created a design issue.
This commit adapts the caret of this dropdown so that it works
correctly when this attribute is defined.
task-3702675
Part-of: odoo/odoo#150886
Single value graph were not shown in cumulated graph.
This is due to unshift happening before the accumulator,
leading to `undefined + X = NaN` for the value.
closesodoo/odoo#162385
X-original-commit: 121aa7e02235c5117bf6be6ccc6c8d6cefe6a744
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Signed-off-by: Florian Damhaut (flda) <flda@odoo.com>
Usecase to reproduce:
- Product wiht a real time valuation
- Product with invoice on delivered quantity
- Create a SO for 5 units and 1000$ each
- Do a full downpayment of 100% of quotation
- Deliver 3 out of 5 units and create a backorder
- Create an invoice
- Validate the invoice
Expected behavior:
The cogs entries are there
Current behavior:
No cogs
It only happens with partial downpayment. When the downpayment amount
equals the quotation amount. An invoice is created instead of a credit
note and the process works correctly.
It happens because it creates a credit note with a negative quantity to
invoice so the system doesn't understand it has to create the cogs at
that point.
closesodoo/odoo#161768
X-original-commit: d2a365c2ee9af6a9272d83183fc75fa6914bc560
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce:
- Install POS app.
- Go to POS settings and enable:
- Is a Bar/Restaurant
- Tips > Add tip after payment
- Open a POS session -if first time, add a floor and a table-
- Add a product
- Click on payment
- Choose a payment method
- Click on Close Tab
- The print popup is shown twice in a row with an empty subtotal amount.
Investigation:
- Inside the `TipReceipt` template, the `total` is not shown as the class lacks a getter for it [1]
- Also when there is no printer, we won't fallback to the web printer as it's annoying to the cashier.
[1]: https://github.com/odoo/odoo/blob/1d49034782e3ff0e4384bad4e927a895e2a97839/addons/pos_restaurant/static/src/app/tip_receipt/tip_receipt.xml#L13-L16
opw-3836549
closesodoo/odoo#161056
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
`l10n_es_edi_sii` requires `Client.bind` as well as `_binding_options`
in the service returned by this `bind` call.
```py
serv = client.bind('siiService', service_name)
if company.l10n_es_edi_test_env and connection_vals.get('test_url'):
serv._binding_options['address'] = connection_vals['test_url']
```
Can be tested with a external l1On unit test,
tested only in nightly builds,
not by regular runbot builds / mergebot.
`--test-tags=external_l10n:TestEdiWebServices`
opw-3888257
opw-3888559
opw-3888155
opw-3890269
opw-3889683
closesodoo/odoo#163123
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Lucas Lefèvre (lul)