This commit fixes an issue where the quickcreate button was missing from
the kanban view when it was grouped by a non many2one field and contained
no record yet (so that no column is shown yet).
Steps to reproduce:
-Go to a kanban view on a model with no record
-Group by as scalar value (eg: Description)
->The "New" button disappears
OPW-3459808
closesodoo/odoo#143793
X-original-commit: 112ba1cb64b5170fdefd267de8e765f87b444b56
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
This commit prevents the editor to search for anchors when the link URL
is an email. This way we prevent an error in the console.
Related to runbot-18747
closesodoo/odoo#143791
X-original-commit: e767c7d4b0ccdeb016cf224b80e269afce4b3028
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
The aim of this commit is verifying that the partner for who
we want to generate an oioubl file has a vat number set.
no task id
closesodoo/odoo#142684
Signed-off-by: Laurent Smet (las) <las@odoo.com>
In grid mode, if an image is in an image column (with the class `o_grid_
item_image`), it has the "Position" image option, allowing to select
between "cover" (= the image takes the whole grid-area, which means it
could be "cropped") and "contain" (= the image is entirely visible and
keeps its ratio in the available space). When there is a shape on the
image, this option is hidden and it is "contain" by default (or else the
shapes would be cropped). See commit [1].
Commit [2] added the "On Hover" animation option, to add hover effects
on images. In order for the effect to be applied, a shape is needed and
if no shape is specified, a dummy square shape is used instead. As there
is a shape, if it is a grid image, the "position" is forced to "contain"
(because of commit [1]).
The issue is that while it is logical for some hover effects to never be
"cover", as they could be cropped (i.e. "Dolly Zoom", "Outline", "Mirror
Blur" and any effect with a shape selected), it is not the case for the
other effects when there is no shape.
This commit improves this by allowing the "Position" option to be used
with these other hover effects when no shape is selected (so only with
the dummy square shape).
Steps to reproduce:
- In edit mode, drop the "Banner" snippet.
- Add the "Overlay" hover effect on the big image.
=> The image became "smaller" because it was forced to "contain".
[1]: https://github.com/odoo/odoo/commit/faf19ef7f87fc043fb9a814516e01b8eeafd9b61
[2]: https://github.com/odoo/odoo/commit/7f730f81ec541cc7791fc6b3fded17c838433f85
task-3568406
closesodoo/odoo#141468
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
What are the steps to reproduce your issue?
Price Decimal Precision set at 5, currency at 2. Anglosaxon enabled.
Have a product with a unit / purchase cost of 3.30125
Create Purchase for 1500.00 and receipt in.
This creates an SVL and AML for 4951.88
Create Bill with unit cost of 3.30125 and total amount of 4951.88
Confirm Invoice
What is the current behavior that you observe?
The layer unit price value is calculated unrounded (line 304, purchase_stock/models/account_move_line.py) - so 4951.88 / 1500 = 3.30125333333.
This is then subtracted from the Invoice unit price leaving a difference of 0.00000333333
Despite the price_unit difference being less than the precision this then multiplies out to be 0.005 that gets rounded to 0.01.
A new SVL layer is created, and a new move valued at 0.01 and remaining value on existing correct layer is reduced by 1c.
When anglosaxon attempts to reconcile the various moves, it is unable to because there is now a 1c difference in the sum of the relevant AML's.
What would be your expected behavior in this case?
Not to create useless SVL that is wrong
Reconcile anglosaxon records normally.
It happens due to the comparaison between the layer price unit that
is not rounded and the price unit of the account.move.line that is
rounded to the decimal accuracy. We want to keep the most accurate
value so we modify _get_gross_price unit to recompute the unit price
this way we ignore the rounding
close#140410closesodoo/odoo#143768
X-original-commit: 73aaaa9550b15225e25fcd750ebfd5fb58436064
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
before PR:
when searching a product that doesn't exist in the
shop, the error message "no results found for ..."
appears, but when searching another failed product,
we hit the cache and the same "..." is displayed.
after PR:
avoid using the cache for the empty results
message
opw-3496581
closesodoo/odoo#143611
X-original-commit: 545a6983146d7e1b0c03ec632c3db72116b1b744
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, error message like "Uncaught Promise" were
translated. However, it may happen that the error is created (and
thrown) before the translation service is ready, i.e. before the
translations are loaded. Indeed, the error service is started first
and starts listening on errors that might be raised. If a module
throws an error (e.g. rejects a promise) before the localization
service is started, the error service being already set up, it
catches it and instantiates the appropriate Error. Doing so, a
"translation error" is thrown as translations aren't ready yet.
Translating those messages makes little sense anyway, as they
target developpers and they can't be found in the code if they
are translated. This commit thus stop translating them.
Issue found while investigating on opw 3602193
closesodoo/odoo#143551
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Prior to this commit, products without assigned categories were not
displayed in the sales details report. This issue was due to the
report's logic excluding products that did not fall under any
specific POS category.
This commit introduces a change where products without categories are
now considered under a default category named "Not Categorized" in the
sales report. This ensures that all products, regardless of category
status, are accounted for and visible in the sales details, improving
the comprehensiveness and accuracy of the report.
opw-3594985
closesodoo/odoo#143440
X-original-commit: 6b7afc9f16133314ff6247f11db002bd3a64d289
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Before this commit, browsers added suggestions when focusing fields.
This commit removes these suggestions.
Warning: there are two kind of autocompletion. One which suggests data
you already entered and completes only the current field if chosen.
The other is auto-fill which suggests your personal info like
email, address, ...
Only the first kind is fixed here, the second cannot be removed at the
moment.
task id: 3114291
closesodoo/odoo#143854
X-original-commit: 201cc48b50b374ea9445f0d148c4e0faeb825327
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Fix the email designer fullscreen icon size by adding the .img-fluid css
class to make the icon image responsive and ensuring it won't scale
beyond its parents.
For screens of max-width 1135px, a css rule applies a 100% min-width
on every only child image which doesn't have the img-fluid class.
This min-width rule was making the icon size bigger than it's actual parent.
Setting the img-fluid class on the image icon for it to not match this rule
fixed the issue.
Task-3604699
closesodoo/odoo#143831
X-original-commit: f5be98b29ac1efb9f547e38d0fde4e65dcc5b8a6
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Amélie Dieudonné (amdi) <amdi@odoo.com>
The current shortcut used to create a todo is already a shortcut on
Windows used to switch to lens view, which is impractical.
It was changed from "Alt + Ctrl + L" to "Alt + Shift + T".
closesodoo/odoo#143805
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The bus service communicates with the websocket worker in
order to deliver messages coming from the bus. Most of the
time, it is using a `SharedWorker` but when this kind of
worker is not available, it fallbacks on a `Worker`.
During tests, the `SharedWorker` is mocked to prevent opening
websockets on the server. However, the `Worker` is not.
Since [1], opening websockets during tests is forbidden thus,
any test relying on `Worker` and expecting a connection to be
established would fail.
This PR solves this issue by mocking the `Worker` constructor
as well.
[1]: https://github.com/odoo/odoo/pull/141519closesodoo/odoo#143988
X-original-commit: 1c67542decb1b6ad38fd15532cb6ac82417ca6dc
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
- Messaging menu was slow when there are many mail failures
- Discuss app is slow whenever there are many pinned threads
- Initial page load was slow when pinned threads were group chats
with hundreds of members
All these performance issue come from aggressively eager call
to reactive callbacks, which `onChange()` and `compute()` were
relying on.
This commits fixes the performance issue with:
- Update cycle in `@mail/record`, which calls eager computed fields
and onChange at the end of an update transaction in discuss models,
so that computation is called only once rather than many times
(while only the later value matter)
- Add support for lazy computed fields (which they are by default),
so that computed fields are only computed when needed.
- Add support for sorted many fields, which also follow the update
cycle and eager/lazy mode of field. This makes sorting operation
on many fields efficient and preserves eventual correctness of
expected order of items in these relational fields.
With module `contacts` installed and populate `--size="medium"`,
init_messaging and mail_failures took 12sec. for Mitchell Admin.
With this commit, this has been reduced to 1sec.
closesodoo/odoo#143382
Related: odoo/enterprise#51410
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Previously, if there were multiple loyalty programs with different
sets of rules, all of them would appear on the receipt, regardless of
their applicability to the order. This caused confusion as it included
programs that were not actually applied to the customer's order.
This commit addresses the issue by altering the receipt logic. Now, a
loyalty program will only be shown on the receipt if it has either
awarded points or had points redeemed in the specific order. This
ensures that only relevant loyalty programs are displayed, enhancing
clarity and accuracy in customer receipts.
opw-3608570
closesodoo/odoo#143376
X-original-commit: d4b366f2d741f2087a947d61d7e0618492cc2bf1
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
* = test_read_group
Currently, a search with the following domain `[('m2m_field', '=',
False)]` will return only the records for which the m2m field is actually
empty and not take access rights into account. This means that, for a
given user and depending on access rules, `record.m2m_field` can give an
empty recordset while a search using the previous domain won't return
this record.
This behavior is problematic when such a domain is returned by the
read_group. Indeed, when using read_group to group on a m2m field,
records for which this m2m field appears empty for the current user will
be counted in the column 'False'. However, the domain associated to this
column is not always valid, as this m2m field can appear empty for the
current user but still have records in it that the current user does not
have access to. Such records won't be returned by a search performed
using the domain returned by the read_group for the False column.
closesodoo/odoo#143233
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Steps to reproduce:
- Enable the merge on account.account in data cleaning APP (in debug)
- Create an invoice with a receivable account = A
- Define a lock date after the invoice date
- Go to chart of accounts
- Select your receivable = A et receivable = B
- Action = Merge accounts where B is the MASTER
Issue:
Upon revisiting the customer invoice: Notice that the journal items have been updated.
Solution:
We simply prevent ~~the use of a nuclear weapon~~ the merge of `account.account` as there other possibilities less dangerous such as multi-edit + archiving
We also prevent the merge of `res.partner` if this one is used in hashed entries
oe:https://github.com/odoo/enterprise/pull/47053
opw-3389157
closesodoo/odoo#142937
X-original-commit: bc66f698e2c4edf2cedce4637dfb7aafaf119251
Related: odoo/enterprise#51170
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
For each product of the shop page (if the template was enabled ofc),
a call to `_is_in_wishlist` would be made, triggering one query to find
the wishlist belonging to the current customer.
This is now done only once in the controller to load all the wishlisted
products.
This code was previously taking up to 15% of the loading time, even when
no wishlist were ever created on the database.
Now, in the best case (no wishlist, standard situation), the time taken
went down to 0.05% of the loading time, gaining > 100 ms of loading time
(when website_sale_wishlist is installed and the template is not disabled).
closesodoo/odoo#142860
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
After profiling and investigation of /shop route flamegraphs,
we have noticed that the rendering of attributes filters
is taking up to 70% of the loading time.
Since attributes are a not so frequently modified and do not depend on
any other contextual data, this part of the template can be easily
cached to improve loading time.
Part-of: odoo/odoo#142860
product prices are dependent of so many factors (taxes, pricelist, fiscal position, ...)
that caching them is either wrong or unproductive (because of the complexity of the cache to manage).
This commit removes this specific cache.
A dedicated performance review is done in the same PR to make sure
the performance is optimized as much as possible.
Part-of: odoo/odoo#142860
Checking on the searched products whether they have tags (through the field) before searching
for them is highly inefficient, will fill the orm records cache for "nothing",
and will be executed in slow, separate queries, highly slowing down the /shop
page loading time.
Part-of: odoo/odoo#142860
Before this commit:
When a user removes Discussion subtypes, the thread is automatically
deleted and also its relational field. Subsequently, a getter
method responsible for retrieving the name to generate the title
fetches it from the 'partner' _field, which is now undefined,
leading to a traceback.
Desired behaviour after this commit:
Saving the 'name' in the state will enable the getter to retrieve the name
even after the record is deleted.
task-3590756
closesodoo/odoo#142643
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When changing the demand quantity on a draft picking line or on a production order,
the related stock.move that should be in draft will be confirmed.
This is because the write function incorrectly calls _recompute_state on draft moves.
Also for mrp, using the split function on draft moves will mark the stock.moves of the new
production order(s) as confirmed because that's the only state given by _get_backorder_move_vals.
This is also fixed.
closesodoo/odoo#142528
Signed-off-by: Steve Van Essche <svs@odoo.com>
In this commit we update the lists of modules from `_eslintignore` and
`jsonconfig.json` such that they now contain all pos modules.
In addition, we also create script in the `tools` directory of pos that
returns a list of all the pos modules. This list is often very useful.
closesodoo/odoo#142366
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Currently the following precaution is taken to not "lose" taxes
when reloading the chart template:
When the tax associated with an xmlid changes,
we "backup" the "old" tax (name prefixed with '[old] '; xmlid removed)
instead of just overwriting it.
Currently only active taxes are prevented from being overwritten.
This commit ensures that also inactive taxes are "protected".
closesodoo/odoo#142294
X-original-commit: 80babc7806cfeb1319cc857f14ea51cf8a224fd7
Related: odoo/enterprise#50806
Signed-off-by: Josse Colpaert <jco@odoo.com>
Co-authored-by: Wolfgang Taferner <wolfgang.taferner@wt-io-it.at>
[IMP] l10n_at: EC sales list
[FIX] l10n_at: wrong tax mapping
[FIX] l10n_at: description on the invoice should be neutral
[FIX] l10n_at: new version
X-original-commit: c42b4e682195d20c253c97e762dd57cf6859b492
Part-of: odoo/odoo#142294
Co-authored-by: Wolfgang Taferner <wolfgang.taferner@wt-io-it.at>
[IMP] l10n_at: more balance tags for details
[IMP] l10n_at: add more tags to organize
[IMP] l10n_at: add additional fiscal positions for auto detection
Unfortunately the rules do not allow to have less fiscal positions
as vat required is prioritized before country.
X-original-commit: eabb0c385534a9612074807ab378bc36a4bc6097
Part-of: odoo/odoo#142294
Co-authored-by: Wolfgang Taferner <wolfgang.taferner@wt-io-it.at>
[FIX] l10n_at: add missing tax (§ 19 Abs. 1e) + better inline references
[IMP] l10n_at: extend KZ 021 to have one tax for each use case
[FIX] l10n_at: tax groups and tags
[IMP] l10n_at: Import Taxes Use Case simplified
[FIX] l10n_at: remove tax as not understandable for everyone
Reduce the profile of this tax to a minimum to keep existing configurations as the former configuration is wrong and the newer one is to difficult to understand, but might be improved or explained properly in the future.
X-original-commit: a605a08173178d361f300f4d4bf8c3afc90c1273
Part-of: odoo/odoo#142294
Co-authored-by: Wolfgang Taferner <wolfgang.taferner@wt-io-it.at>
Currently the tax_scope field is never used and thus the column does
not exist.
An empty column is introduced in this commit.
It will needed for the following commit.
The commits are kept separate to make it easier to review the actual
changes in the next commit.
X-original-commit: d12f5e301eaa9a31c6e2e2b3c984857d573ddd33
Part-of: odoo/odoo#142294
To be approved for the bookkeeping act, we need to generate reports
based on tags instead of account codes. It allows users to link
their existing CoA to the one we decide. To do it, they can add the
right tags on their own accounts.
This commit adds necessary tags to handle auto generated accounts
(like suspense account) and assigns these tags to the right account.
closesodoo/odoo#143820
Task-id: 3593634
Related: odoo/enterprise#50676
Signed-off-by: John Laterre (jol) <jol@odoo.com>
This commit updates the localization to be compliant with
the new Danish Bookkeeping Act.
The chart of accounts has been adjusted to strictly comply with the standardized chart of accounts provided by the Danish government
The taxes have been completely reworked, but still re-use the existing tax grids as they are unchanged.
Part-of: odoo/odoo#143820
When opening the calendar view in, for example, the timesheets app, the first
day of the week used for the number calculation is provided by the localization
service, which in turn requests it from the database. Because the first day of
the week is stored as a number between 1 and 7 in the res.lang model and a
value between 0 and 6 is expected by the DateEnv, offset errors can occur.
The error is fixed in various components (for example, the CalendarDatePicker
and CalendarCommonRenderer) but not in others (CalendarYearRenderer). Instead
of patching each component separately, a better solution is to require the
CalendarModel to expose a 0 to 6 firstDayOfWeek value as part of its public
interface.
opw-3389617
closesodoo/odoo#142056
X-original-commit: aea22a46515304df41dfaf427f5955824fe342f5
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
With this commit, we have improved the UI for the Prepayment amount field
in both the quotation template form view and the Sale order form view.
The changes have made it easier for users to input and review information.
task-3546106
closesodoo/odoo#139461
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce
---------
* install the German localization
* create and print an invoice
You should see that the 'total' block and payment reference are not
correctly aligned
opw-3524254
closesodoo/odoo#143830
X-original-commit: da1de44392fb5ffe07bc5ee7244538d5a3056596
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
A custom script is modifying the output of
load_information_from_description_file to disable the
auto-install of modules during local testing. It was naively adapted for
v16.0 by replacing the corresponding methods. Since a lru cache was added
(nice optimization in most cases) this is an issue because running lint
test afterward will get the cached value with an incorrect autoinstall
value. It makes sens to avoid reading the file on the filesystem each
time, but making a deepcopy looks like an acceptable safeguard to avoid
hard to debug behaviors.
closesodoo/odoo#143628
X-original-commit: ad10ff4410ccf7c38f6154480484495bb57c53ff
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
add l10n_es_type 'ignore' on Subtract Base (DUA) -100% tax so that it
can be ignored when creating Libros export
closesodoo/odoo#143314
Task-id: 3604971
Related: odoo/enterprise#51366
Signed-off-by: Josse Colpaert <jco@odoo.com>
Before: No lituanian translation was created for this version about
the number of remaining products in stock on website ecommerce page.
Step to reproduce:
- Create a db with the website_sale_stock module
- Configure a product in sales tab: active Show available qty with
only if below 1000
- Add lituanian language
- Go on the product page on the website and change the
lanuage in lituanian
Now: Translation added
opw-3560842
closesodoo/odoo#142995
X-original-commit: 02cab20ab526d5ca6bd85bb4fa44278814968390
Signed-off-by: Olivier Monnom (mool) <mool@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Steps to reproduce:
- Install Stock and Project
- Create a new proect with current company as customer
(3 dots menu on project overview to the customer)
- Create a new warehouse for the current company
- Error pops
Bug:
since commit[1] check company is enforced on the project_id field of
partners in bothways
when creating a new warehouse CheckCompany fields are editted on the
partner if set (property_stock_customer/supplier) the issue is if
the partner's company_id is False while project belongs to company
"_check_company" fails
Fix:
Remove check company on project_ids from the partner's side and
implement it as python constraint
opw-3507952
[1]:https://github.com/odoo/odoo/pull/109464closesodoo/odoo#143679
X-original-commit: 3741557dc4b5e84876247db851e9d2c862fcb93b
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
This commit adds the missing neutralisation necessary for the `pos_viva_wallet`
module introduced in [1]
The purpose of the standard neutralisation framework is to allow us to
create database copies that will not interract with external systems in
ways that could impact the production database (or if it is not possible
to prevent the interractions, make sure that they are benign or wont
result in actual changes), or impact the customers of the operator of
the production database.
This is mainly useful to allow safe support investigation on database
duplicates.
[1] https://github.com/odoo/odoo/pull/140353closesodoo/odoo#143741
Signed-off-by: Alexandre Moens (mao) <mao@odoo.com>
When using account.root (through account.account().root_id or
account.move.line().account_root_id) in read_group, we can have
inconsistent results because of how account.root is defined.
account_root is a view with the id field computed out of account codes,
but there can be the same account for several companies, so we can have
several same ID for different rows => this is not expected by the ORM
who expects one record by ID => in result, we get for example the values
in the pivot table of journal items be multiplied by the number of
companies if we group by "Account Root".
With this changeset, we add a small optimisation in ORM so if a group by
is ordered by a many2one, if the order of the many2one is "id" we don't
add a left join for ordering.
note: without the change, the added tests failed:
- in account, with 1000 as balance, and 2 as number of root with id=90090
- in test_read_group with a query containing a left join to o2m table
- in test_new_api with a query containing a left join to o2m table
opw-2282699
opw-2289440
opw-3288390
closesodoo/odoo#143257
X-original-commit: 674bdd1ac2cf9a4a3748b85f71ebbd01137485ce
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Steps to reproduce:
- Drop a "Share" snippet anywhere on the page and save.
- Click on the email icon.
- Your default email client should open with, as a subject line, the
title of the page where spaces are replaced by +.
=> This should not be the case, spaces should show as spaces.
Since the sharer refactoring in [1], the title of a page used in share
buttons of the `s_share` snippet is encoded as a `URLSearchParams()`,
which encodes spaces as "+" characters (see the specs [2] of the
built-in method). This works fine for most share buttons, but not for
email clients, which do not properly parse the "+". Typically, that
means that the subject line of the mailto link is something like
"Home+%7C+My+Website", which renders as "Home+|+My+Website" in a mail
client, instead of showing spaces.
This commit uses another way to encode the title parameter, so that it
works for every share button. It also replaces a space that was encoded
twice for Whatsapp.
[1]: https://github.com/odoo/odoo/commit/5297388cd2aa1f693b04538c846c7025e243b09d
[2]: https://url.spec.whatwg.org/#ref-for-urlsearchparams%E2%91%A4
task-3603556
closesodoo/odoo#142876
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
This issue occur When the customer tries to make a payment from Accounting
Dashboard of account module,at that time the error will be generated.
step to reproduce:
- install the `Accounting`.
- open the `Accounting`.
- go to `Accounting Dashboard`
- click on this `⋮` of bank (Right side of top)
- click on the payment of view
- the error will be generated.
error- TypeError
account_journal.open_payments_action() missing 1 required positional
argument: 'payment_type'
(1) - https://github.com/odoo/enterprise/pull/49762
accounting to this (1) PR, One link to "Payments" is enough (rather than
customer,Payments, Vendor Payments, Internal Transfers) > Those filters exist
in the list view of payments
after this commit ,The customer will see "account all payments" if they click on
the payment screen.
sentry-4620831582
closesodoo/odoo#142649
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Some auto-generated field labels don't make sense for translators. For example
field: needed_terms_dirty label: "Needed Terms Dirty"
After this commit, if the field.export_string_translation is False, we don't
export their labels when export translations.
closesodoo/odoo#142329
Signed-off-by: Raphael Collet <rco@odoo.com>
Accounting moved the logic of _get_reconciled_vals
into _compute_payments_widget_reconciled_info but did not made the
change in point_of_sale.
This commit resolve this by putting the logic of the previous
_get_reconciled_vals into an override of the
_compute_payments_widget_reconciled_info method.
This is done because this is a legal requirement in France to have and
maybe in other countries.
closesodoo/odoo#139979
X-original-commit: ad7d4b68b539ad37431734eca3fe59a908cf4e34
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
Before this commit, the form view of the board action is given to the
children views. This can lead to some issues, for exemple in the
following case:
- Add a pivot view to a board
- Click on a cell to open the list view
- Click on a record of the list view to open the form view
=> The form view used is the one of board, which lead to an empty view.
opw-3598945
closesodoo/odoo#143756
X-original-commit: f65efabb938bf5643754c426ad3db813d9eff581
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Have an Invoice partner with type Individual
Create an invoice with said customer confirm.
ZATCA invoice has warning "invoiceTimeStamp_QRCODE_INVALID".
```
{"type":"WARNING",
"code":"invoiceTimeStamp_QRCODE_INVALID",
"category":"QRCODE_VALIDATION",
"message":"Time on QR Code does not match with Invoice Issue Time (KSA-25).
If ZATCA's SDK was used to generate QR Code, kindly use the
latest version of SDK",
"status":"WARNING"}
```
This occurs because when the Invoice partner is an Individual
the validation requires an additional QR code enclosing invoice information
that needs to match the xml content.
In this case the IssueTime of the invoice was not matching because the
QR is manually formatted with a wrong 'Z' at the end, while its timezone
is, correctly, Asia/Riyadh
opw-3586326
closesodoo/odoo#143697
X-original-commit: da50d78ee73661cb2af599e0f4276f3d9a891e16
Signed-off-by: Josse Colpaert <jco@odoo.com>
This issue occurs when the customer creates an operation with a 0.0 expected
duration fields. An error is then generated when the customer creates a
manufacturing order and selects that operation due to expected duration fields
is set zero.
step to reproduce -
- Install the `Manufacturing`
- Click on `Configuration > Operations `
- Create New Operations.
- Select the Bill of Material (ex - [FURN_8621] Plastic Laminate)
- Default Duration fields must be 0.0
- click on `Operations > Manufacturing Orders`
- Create New Manufacturing Orders.
- Select the Product (select the product which you selects while creating
operation ex. FURN_8621] Plastic Laminate)
- Click on the `Overview` button.
https://github.com/odoo/odoo/blob/17.0/addons/mrp/report/mrp_report_mo_overview.py#L268
after this commit, the customer will be able to set 0.0 in expected duration.
sentry-4657725988
closesodoo/odoo#143490
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce:
- Install l10n_sa_edi
- Switch to a SA company
- Create a 15% INCLUDED tax
- Create an invoice:
* Customer: [any]
* Invoice Lines:
- Product: [any]
- Quantity: 90
- Price: 200.00
- Taxes: [the 15% INCLUDED tax]
- Confirm the invoice and process it by ZATCA service
=> The invoice is accepted by ZATCA, but there is the following warning:
"BR-KSA-EN16931-11 :
Invoice line net amount (BT-131) must equal (Invoiced quantity (BT-129)
* (Item net price (BT-146) / item price base quantity (BT-149)))
+ Sum of invoice line charge amount (BT-141) - Sum of invoice line allowance amount (BT-136)"
Cause:
The net unit price (200 / 1.15) has more than 2 decimals but its value is rounded
to the decimal accuracy of "Product Price" (2 digits by default) in the generated
EDI document.
When multiplying its rounded value with the quantity, the result is not equal to
the invoice line subtotal, which is triggering the warning.
Solution:
Remove the rounding for unit price amount as there is no restriction on its number of decimals.
Reference:
- https://docs.peppol.eu/poacc/billing/3.0/bis/#_unit_price_amount
- https://zatca.gov.sa/ar/E-Invoicing/SystemsDevelopers/Documents/20230519_ZATCA_Electronic_Invoice_XML_Implementation_Standard_%20vTrack.pdf
opw-3509940
closesodoo/odoo#143348
X-original-commit: 48a78bed9ad0c10e510b2c3e48e53c4c82ce5761
Related: odoo/enterprise#51469
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Julien Carion (juca)