Buttons "Send message / Log note / Activity" are on two lines instead of
one. In addition there is a 1px glitch on the attachment icon.
Also long attachment name on tiny screens (i.e. iPhone 5) breaks the
composer layout: horizontal scrollbar appears.
The two-line buttons effect is related to a change (fix) in Bootstrap
4.2 which removes the white-space: nowrap on .btn. It was originally
introduced in Odoo through https://github.com/odoo/odoo/pull/29949.
Reference: Original Bootstrap PR https://github.com/twbs/bootstrap/pull/27010
Task ID: 1946573
closesodoo/odoo#31939
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit fixes the document viewer: the document viewer
was altering the `type` key of attachment objects, this issue was causing
matching errors in some cases.
With this commit, the document viewer widget uses its own key `attachment.fileType`
to store the information that used to override `attachment.type`
closesodoo/odoo#32414
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Technically it does 3 different things:
* switch from 1 level of o2m to 2 levels of o2m when recursing
* handles `parent.<xxx>` readonly modifiers on o2m subfields
* handles `id` readonly modifiers on o2m subfields (already worked in the
normal case but not for o2m records from default_get)
The last two especially are temporary quickfixes, that will need proper fixes.
closesodoo/odoo#32428
Signed-off-by: Christophe Simonis <chs@odoo.com>
When creating a customer profile in Authorize.Net we specify a field
merchantCustomerId that is composed of:
ODOO-{partner-id}-{8-random-characters}
But the limit of this field is of 20 characters:
https://developer.authorize.net/api/reference/index.html#payment-transactions
So if we have 1 million partner, we may have eg. a partner 1000005 that
would result in an ID `ODOO-1000005-af123c5b` that is too long and
results in an error.
With this changeset, the generated ID is truncated to 20 characters so
this should theorically be alright for up to 9.99*10^15 partners (the
postgres limit for an integer is 2.15*10^9 so this should be safe
enough).
opw-1962422
closes#32423
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The board created out of a tree view wasn't taking the default domain of
the view.
opw-1958349
closesodoo/odoo#32240
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- currently, cuurency_id has default value as currency of user's company id. but, when there is no partner set then 'onchange_partner_id' will trigger and set currency_id to false.
- so, set user's currency_id instead of false if no partner set.
Related to Issue: 1948645
closesodoo/odoo#32415
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
If bulk-importing clients with a parent_id set, there's a ton of extra /
post-processing work which is not batched and "de-optimises" the
batching added to import.
High-level comparison of performing a "Test Import" on a synthetic test
file of 10000 partners (all with a parent_id set to a pre-existing
record) went from ~30mn to ~8mn on my machine.
Fixes#31549closesodoo/odoo#31876
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Make some invoices
Make a payment
Reconcile it with the invoices through the reconciliation widget
Print the payment receipt and the checks
Before this commit, neither the payment receipt nor the checks contained
the invoices
This was because the prints relied on only the field invoice_ids
filled specifically when registering a payment on an invoice
After this commit, the prints mention the invoices
OPW 1947002
closesodoo/odoo#32365
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The recent refactoring odoo/odoo@f296992 wrongly moved the ace editor
style from `web_editor` to `website`, even though ace is in `«eb_editor`.
The editor is also used in Studio (which does not depend on website) so
the style was missing in this case.
Task 1951290
closesodoo/odoo#32384
Signed-off-by: Christophe Matthieu <Gorash@users.noreply.github.com>
- when no workcenter or no production order, it should not provide option to create work order.
Related to Issue: 1957994
closesodoo/odoo#32411
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When a report with header is displayed in iframe with layout
"Background", part of the header maybe outside of the page.
For example on /my/invoices portal show of an invoice, the max width
report iframe can set at 210mm (+/- 793.7px normally), the header in
background layout has `min-width: 900px` so is wrongly centered and may
have content outside of shown page (eg. company tagline).
The same issue happen when using HTML rendering of the report in
backend, but depends on the viewport width.
This may be the expected configuration when printing (wkhtmltopdf should
unzoom if something was too large to fit) but not when displaying html
directly.
opw-1915807
closes#32373
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Task#1963256
Some fixes for the product configurator recently introduced a bug
in the product template's _name_search method.
Commit: 99bae2cdb7
This commit correctly handles the fact that the "limit" parameter
can be None.
closesodoo/odoo#32363
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Mostly a concern during bulk import of partners with parents.
First remove syncing extended fields, that seems completely
unnecessary since the street gets sync'd and will get split through the
normal process (updating the sub-fields), by also syncing the split
fields we're redundantly calling _set_steet and rewriting the address
we just sync'd.
Second if write()ing both the country and street, the override would
then go and re-write the street based on what had *just* been split
into sub-street fields, which could waste a lot of time during the
import post-process as address fields get moved back and forth between
parents and children leading to *lots* of writing both country and
address together, we're talking:
ncalls tottime percall cumtime percall filename:lineno(function)
10002/2 0.111 0.000 344.390 172.195 res_partner.py:181(write)
[...]
2 0.455 0.228 165.264 82.632 base_address_extended.py:41(_set_street)
My initial instinct was to just add the country_id to _set_street and
remove the write override but it would break
88ff6beb01: if the country alone is
updated on a partner, we do want to re-format the "unified" address
based on individual fields and the new country's format.
Note: it might be that the logic would be more sensible by inversing
the entire thing, such that the split fields are the proper
source (regular stored fields) and street is converted to a computed
field instead, but that'd be a larger model change. Seems like it'd
make more sense though, at least given what the modules attempts to
do (OTOH the module probably fails
https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/
in just about all the ways).
Should correctly handle / fallback to regular code when processing
non-stored partners.
Perf difference according to cprofile on my machine:
original python:
ncalls tottime percall cumtime percall filename:lineno(function)
1 0.134 0.134 205.380 205.380 res_partner.py:277(_compute_commercial_partner)
SQLized
1 0.118 0.118 67.239 67.239 res_partner.py:280(_compute_commercial_partner)
most of the time leftover seems to be in modified_draft
With profiling enabled, importing 10k partners, with all of them
having the same parent (though not with all of them having the same
is_company setting) lowers sync / post-process time from ~550s to
~330s.
Put it in an override to _load_records_create so it's only active for
imports (which is the original report & test case), use a context key
to avoid going the post-processing work in create.
- Go to Sales > Configuration > Settings
- Enable "Multiple Sales Prices per Product" and select option "Prices
computed from formulas (discounts, margins, roundings)"
- Go to Sales > Catalog / Pricelists
- Select "Public Pricelist" and set "Discount Policy: Show public price
& discount to the customer"
- Go to the eCommerce, buy "iPad Retina Display" which as a 20 %
discount
In the corresponding SO, the discount appears to be zero, and the
discount is included in the price unit. However, adding the product
directly to the SO in the backend displays the discount as expected.
There should not be a difference in behavior between the eCommerce and
the backend.
Fixes#31337
opw-1943989
closesodoo/odoo#31965
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Activate multi-company, but do not share contact book.
- Create 2 companies A & B
- Create a partner named 'PartnerA' in company A
- Switch to company B
- Import a bank statement with partner name set as 'PartnerA' (use the
bank statement template if necessary)
- Reconcile the entries
An `AccessError` is raised.
The partner suggestion doesn't take into account the record rules,
therefore it might happen that the user doesn't have access to it.
opw-1958711
closesodoo/odoo#32239
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In case two modules are using the same local name for their external identifier,
a conflict may occure.
e.g. the templates
- l10n_generic_coa.a_salary_expense
- l10n_be.a_salary_expense
will generate
- l10n_generic_coa.1_a_salary_expense
- l10n_be.2_a_salary_expense
As the previous search for in_xml_ids was using a domain
('name', '=', 'a_salary_expense')
both records were returned, making in_ids to have one more record than out_ids
Followup of review made at odoo/odoo#31510closesodoo/odoo#31604
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When creating a record from a calendar view,
the default form view is always used when using the popup mode,
ignoring the `form_view_id` attribute of the <calendar/> tag.
After this commit, the `form_view_id` is no longer ignored.
closesodoo/odoo#32379
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
- Set your fiscal year end date to 28th February
- Run the P&L a year before a leap year, e.g. anytime between March 1st
and December 31st 2019.
- Select 'Last Financial Year'
The dates are set from 2019-03-01 to 2019-02-28.
There are actually 2 bugs. The one solved here is the following
inconsistency:
```
current_date = type(date)(2019, 4, 3)
date_utils.get_fiscal_year(current_date, day=28, month=2)
'date_from': datetime.date(2019, 3, 1), 'date_to': datetime.date(2020, 2, 28)
current_date = type(date)(2020, 2, 28)
date_utils.get_fiscal_year(current_date, day=28, month=2)
{'date_from': datetime.date(2019, 3, 1), 'date_to': datetime.date(2020, 2, 29)}
```
Both should return `'date_to': datetime.date(2020, 2, 29)`. This implies
that the period is recognized as `custom`, which is affected by the bug
solved in PR https://github.com/odoo/enterprise/pull/4006
opw-1949628
closesodoo/odoo#32366
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce:
- Create a storable product P with a vendor V and a purchase price = 100€
- Set the category of the prodcut to automated and AVCO and set a price diff account on it
- Create PO for V with 10 P with a price_unit = 110€
- Confirm the PO and deliver 7 P with no backorder
- Change the ordered quantity of P to 9 on PO (and the unit_price will be set to 100€)
- Go on the delivery order and deliver 2 remainig P
- Create the invoice and validate it
Bug:
The amount due on the invoice was 900.02€ instead of 900.00€
PS: The debit and credit of an aml are computed with the price (defined in function
_anglo_saxon_purchase_move_lines) with the function _convert_prepared_anglosaxon_line
defined on model account.invoice. So rounding the price unit after the computation
of the price allows to keep the same total as the one computed for the PO.
opw:1951465
closesodoo/odoo#32345
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When we go on a failed mail.mail and do "Retry" -> "Send Now", if there
is an existing notification that is not to the current user, we may get
an error or get the email in error.
This is because on a notification only:
- the superuser
- the targetted user of the notification
have write permission by default in Odoo.
So with existing notifications resending (by the mail.mail views, the
alternative mail.resend.message wizard works as expected) only worked
if they were current user's notifications or if user is superuser.
opw-1957730
closes#32346
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Test was relying on qty_to_consume getting saved when the produce form
is saved, a behaviour of the SSF which diverged from the actual
client.
After fixing the SSF to behave more in-line with the actual
client (don't save o2m sub-fields unless they're flagged as
force_save) the test is now visibly broken.
Fix it so qty_done is properly updated during wizard configuration /
edition instead of updating the in-database object directly.
closesodoo/odoo#32047
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The SSF would correctly filter out readonly fields when saving a
toplevel form, however it could not remove readonly values when saving
o2m pseudo-records to the parent form (as these would be expected to
remain available for reading upon the next edition and whatnot), so
these values would get sent in 0/1 commands.
Filter out these fields during the parent / toplevel save call.
Complexity notes:
* evaluating readonly modifiers requires the entire record, so
unchanged fields still have to be written back to the parent form
and be filtered out when *it* is set up for save, an alternative
would be to store the `changed` and `readonly` flags alongside the
record dict, and have the post-process only override the
pre-computed readonly flag using force_save
* had to fix a test to match the new behaviour, the post-edition
states turns out to be in line with the client's behaviour (or how
it looks anyway)
Fixes#32019
The extra setup probably affects any o2m whose edition view itself
contains an o2m, but most likely to blow up entirely on models with
some sort of tree structure (parent/child relationship): the SSF
eagerly loads and setups the o2m's view, and the o2m's o2m's, ... ad
infinitam.
A better / cleaner fix would be to set up the subview on-demand (and
possibly cache it), but the rest of the o2m stuff is unlikely to work
correctly recursively so just don't recurse the o2m view setup at all
for now.
fixes#31458
Deprecated accounts are available in the reconciliation widget, while
they shouldn't be.
opw-1949667
opw-1945585
closesodoo/odoo#32304
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
`res.partner.bank` is ordered by sequence, but:
- there is no default value
- there is no widget handle to set it
Therefore, methods such as `_get_partner_bank_id` might retrieve an
unexpected value.
To avoid this:
- we fallback to sort by ID
- we add a default value
- we add the widget handle
opw-1948964
closesodoo/odoo#32300
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Set a company on the inventory location
- Create a stockable product, FIFO, real-time, with a cost
- Receive a unit
The product stock value remains zero.
The fact that the inventory location has a company set should not impact
the product cost. This is useful when a scrap location as a company set.
The domain of move selection is incomplete. It should be, for the 'in'
moves:
- coming from a location without company, or an inventory location
within the same company
- going to a location within the same company
For the 'out' moves:
- coming from to a location within the same company
- going to a location without company, or an inventory location within
the same company
opw-1943384
closesodoo/odoo#31485
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
PRs #28645 and #31494 were not applied to 12.0, but there's no reason
not to, they should only fix things (make behaviours more in-line with
the regular client), and since o2m is an area where more fixes are
needed and it would be nice to have them in 12.0...
To be able to override the initialisation of the work orders states,
we put that in a function.
opw 1943674
closesodoo/odoo#31774
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
This commit is not needed (and not wanted) in saas~12.1 due to
07bef887af that convert field
`move_ids_without_package` to a computed field with an invert method.
The invert method writes on `move_lines`, which will recompute the value
of `weight` field correctly.
This reverts commit b2b395467f.
Pierre Paridans