Avoid crash at currency conversion when no company is set on the SO
opw-2009044
closesodoo/odoo#34408
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Install stock module
- Activate multi-company and variants
- Create a second company
- Create a product with 2 variants
- Create a picking with the product for both companies
- Add an attribute on the product with 2 values
- Save
An AccessError is raised on `stock.move`.
It arises because the field `product_qty` on `stock.move` must be
recomputed but is on a record in a different company.
The `try` / `except` clause doesn't protect against the recomputation.
Indeed, what happens is:
- try to unlink in batch => AccessError due to recomputation
- try to unlink individually => AccessError due to recomputation
- try to write individually => the field couldn't be recomputed before
(flagged as dirty), so try again to recompute => AccessError
We perform the operation as sudo, and take care of checking the access
rights beforehand.
opw-2009450
closesodoo/odoo#34369
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
There is no guaranty that both the request body and the response body
will contain JSON data. This fix corrects the logging by printing the
raw text in case of json decode error.
opw-2006561
opw-2024242
closesodoo/odoo#34221
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
The tags set for TVA déductible (achat) 5,5% TTC were for "TVA collectée"
opw:2026360
closesodoo/odoo#34410
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
1. Setup a few variants for a product;
2. Create a BoM for each of the variants with different
components/quantities, make sure to specify the product variant field;
3. Go to any of the variants and click Print BoM Structure.
Before this commit, it will print the BoM structure for all variants and
not only the one selected. Also, it will print in all the variants the
same BoM structure. If multiples BoM were selected to print, each
variant of the product was printed with each of the BoM structure
selected.
Now, if you select one BoM, only this is printed. If multiples BoM are
printed, each product, and product variant are correctly related to
their respective BoM structure.
opw-2007939
closesodoo/odoo#34353
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce the bug:
- Create a finished product P with a manufacturing BOM B
- Set two components on B C1 and C2
- Create a MO with P and process it(plan and produce it)
- Unlock the MO and set the consumed qty of C1 to 0
- Lock and click on Mark as Done
- Click on Cost Analysis
Bug:
C1 was displayed in the report with a qty = 1.0
opw:2010912
closesodoo/odoo#34351
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The `timesheet_uom` widget is a proxy to another widget (configurable
server-side). We need to ensure the widget registry is filled before
using it to avoid a fallback to `float_factor` widget.
closesodoo/odoo#34350
Signed-off-by: Christophe Simonis <chs@odoo.com>
In case a many2one field (let us say 'foo') is used
simultaneously as a groupby and a measure in the pivot view,
the values returned by a read_group for that many2one are of
the form [id, label] and the aggregated values (always 1) are
missing in the read_group results (datapoints).
Thus typically, a datapoint is of the form
{'foo': [1, 'Bar'], '__count': 4, ...}
and does not contain information on the 'foo:count_distinct'
value (this is a read_group bug).
As a consequence, a special processing of the read_group
datapoints is done in the pivot model to handle that
situation and the value for 'foo:count_distinct' is infered
correctly to be 1.
In the pivot comparison mode, datapoints comming from the
period and the comparison period (data and comparisonData
sets) are identified if they have same values for the groupby
fields and the measure values become small objects containing
information on the the measure values for data and for
comparisonData and on the related variation.
Thus
{foo: [1, 'Bar'], __count: 4, ...}
from data and
{foo: [1, 'Bar'], __count: 3, ...}
from comparisonData should become a single datapoint
{
foo: [1, 'Bar'],
__count: {
data: 4,
comparisonData: 3,
variation: {
magnitude: +33 (%)
}
}
fooAggregate: {
data: 1,
comparisonData: 1,
variation: {
magnitude: 0 (%)
}
}
It turns out that the code responsible for merging the data
and comparison datapoints made a mistake by mixing the keys
'foo' and 'fooAggregate', with the consequence that the
variations were not correctly computed in the situation
described above.
This is fixed in this commit.
closesodoo/odoo#33118
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Make the 'Custom Message' field translatable since it is supposed to be
used on the website and displayed in the language of the user.
opw-2008088
closesodoo/odoo#34344
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, when receiving a new message from a hidden chat
window, it was making it visible. Because of this, if we had focus
on any other window, the focus was lost. Even more annoying, if we
had focus on the left-most visible chat window, it moved to hidden
menu, so that new chat window takes its place.
This commit fixes the issue by keeping new chat windows hidden
on receiving new messages, in case there is not enough available
space.
Task-ID 2026101
closesodoo/odoo#34291
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
- Set 2 banks accounts for a partner A
- Create a credit note
- Choose partner A => a default bank account is chosen, and both are
available in the list.
- Save, go back to the tree view, then reopen the same credit note
It is not possible to choose among both bank accounts anymore.
It is due to the domain set on the view, which is valid for customer
invoices but not for credit notes. It works at creation since
`_onchange_partner_id` overrides the domain for `out_refund`.
In this specific case, a domain in the view is not appropriate: the same
view is used for 2 invoice types although they require a different
domain. Therefore we set the domain only in the onchange. The drawback
is that all bank accounts are shown when we reopen a customer invoice or
a credit note from the tree view since the onchange is not triggered.
However, the constraint `validate_partner_bank_id` still protects
against an incorrect configuration.
opw-2010017
closesodoo/odoo#34292
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In certain case, a non blocking traceback pops-up.
It happens when the page loads, if the dom is modified
before the tour has been fully loaded.
Theorical steps to reproduce:
- Open a page with an active tour
- Trigger any domain change before the tip-dot is loaded
On every change in the DOM, the MutationObserver tries
to update the page. If the tip-dot has not been loaded yet,
it will try to update the position of a non-existing element.
In that case, we simply ignore it. The update will be called
anyway when the tip-dot has finished his loading.
opws:
1923348
1965964
2011027
2008708
2001867
2000228
1998906
1972914
1972629
1963173
1961373
1956962
1949591
1947390
1947286
1944577
1944459
1941764
1938887
1936518
1935831
1934788
1934471
1934225
2006977
1970672
1931721
1931593
closesodoo/odoo#34199
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Configure Stripe with 'Save Cards' set to 'Let the customer decide' or
'Always'.
- Go to the eCommerce, buy an item
- Use Stripe to pay, make sure to check 'Save my payment data'
No payment token is saved.
It occurs because 2 calls are performed to `/shop/payment/transaction`.
The second call, which is used to record the transaction, doesn't
contain the `save_token` parameter is not sent.
Ideally, we should only make a single call, but since Stripe works a bit
differently, we can't prevent it (in stable, at least). Therefore, we
work around it by searching the checkbox value.
opw-2008275
closesodoo/odoo#34242
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Set the 'Editor Features: image and links' karma point to zero.
- Set a user with a total karma points < 30
The user doesn't see the links buttons in the editor.
This is because of an old fallback from 2014 which doesn't make sense
anymore today.
opw-2026025
closesodoo/odoo#34325
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Set the building icon next to the rounding method label since it is a
multi-company setting.
opw-2026025
closesodoo/odoo#34315
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
For custom fields, the _module attribute is False, this means that
during the reflection of the model, the custom field's xmlid would be
set up as being introduced in the module of its model's original
definition, which is wrong (because it has no module).
E.g. field x_foo introduced in my_mod by extending model bom from
mrp, the resulting xmlid would be `field_mrp_bom__x_foo` when in reality
it should be `field_my_mod_bom__x_foo`, however this patch simply
disables the feature for custom fields as there is little to no use for
them to have an automatic xmlid.
Task-ID: 2025151
closesodoo/odoo#34265
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this commit, in project overview, there was an advance payment
line under 'Timesheets' section which was unnecessary for the timesheet.
After this commit, down payment line will not considered in project overview.
task-1957272
closesodoo/odoo#34062
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
- From Accounting dashboard > Configuration panel > Configure fiscal year
- Set opening date: 01/07/2018
- Set fiscal year end: June 30
- Click Apply button
An error is raised: 'Invalid fiscal year last day'.
This is because the 3 fields are linked by the constraint
`_check_fiscalyear_last_day`. However, non-stored writeable related
fields are evaluated one at a time, meaning that the constraint is
evaluated one value at a time.
We do a fancy workaround to write the 3 values at once on the company,
hence evaluating the constraint for the 3 fields once.
opw-2024927
closesodoo/odoo#34275
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Configure your system to be in the Mexico timezone, configure your Odoo
profile accordingly. Go to calendar, show daily events, add an event at
the end of the day (like 10pm). The resulting event is not visible on
the daily view although it is on the weekly view. The same problem
occurs on the weekly view if the event was create late the last day.
The problem is the initial `search_read` has a domain to filter the
events using 00:00 UTC to 23:59 UTC boundaries. Those boundaries are not locale
aware, they should be shifted to the MX timezone.
opw-2009877
closesodoo/odoo#34247
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
The field module_account_accountant is called "Account" in account module
but was changed to "Account Accountant" in hr_payroll, making the source of
a translated record to change based on the module installed (which can lead
to confused translators or broken universes)
Terms export was unified at #34296closesodoo/odoo#34298
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The view content was changed at 3b5f33281d but the changes were not
reflected in the pot file
opw-2025750
closesodoo/odoo#34296
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
As we will move those from other localizations to base,
we add those for Mongolia to base already.
closesodoo/odoo#34281
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
DROP CONSTRAINT (even with IF EXISTS is specified) acquires an ACCESS
EXCLUSIVE lock on the table, preventing e.g. inserts in an other
transaction, so ir_logging would systematically deadlock if configured
to the same database and a warning would be triggered during install
or update (if that ran ir.logging's init).
1. hand-roll the "IF EXISTS" bit, to avoid taking an ACCESS EXCLUSIVE
lock on the table if the problematic constraint does not exist and
thus doesn't need to be dropped (which by now should be the vast
majority of cases).
Replacing DROP CONSTRAINT with DISABLE TRIGGER does not fix the
issue as *that* acquires SHARE ROW EXCLUSIVE. While that's less
constraitning than ACCESS EXCLUSIVE, it still conflicts with an
insert's ROW_EXCLUSIVE.
2. add a timeout to the logging INSERT anyway, the deadlock is still
an issue if we're updating a database which does have the
problematic constraint, and we want to preclude the possible
eventual introduction of new deadlocks in the future.
closesodoo/odoo#34243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The fix added in 3a0f05f334 doesn't work if an already existing user in company A
trys to modify his address on a website linked to company B. The form will try to change the company_id
of the res.partner which will then conflit with the company_id of the associated res.user, ultimately leading
to a UserError and a 500 error on the website.
opw-2025457
closesodoo/odoo#34262
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Commit 6b14ceb225 introduced a smarter way to find the default
journal based on the currency. However, it missed the fallback if no
journal is found.
opw-2009934
opw-2024204
opw-2011321
closesodoo/odoo#34263
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Create an hr.leave.allocation with mode = 'By Employee Tag'
- Select Employee Tag = 'Employee'
- Set all the other required values
- Log with Demo User(Marc Demo)
- Go to Leaves > My Leaves > New Request
Bug:
An access right error was raised due to the record rule: "Allocations: employee: read own"
With this record rule the user can only read the hr.leave.allocation linked to his employee's user.
But with allocations in mode 'By Employee Tag', in the function get_days it tried to compute
the 'number_of_hours_display' of all the allocations linked to the current employee's user and
in the function _compute_number_of_hours_display, it also computes the parent_id of these allocations.
As the parent_id is not linked to the employee's user, it raised an access right error.
opw:2006686
closesodoo/odoo#34236
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The months name in momentjs used an arabic translation with the month
then some crap (or the month said a second time) after.
This does not seem expected, and has been solved in moment.js library 2
years ago:
https://github.com/moment/moment/pull/4271
This PR apply this change in moment.js localization included in Odoo.
opw-2006265
closes#34248
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
A pie chart widget aims to instantiate a graph view in mode
'pie', with a measure and a single groupby specified via some
attributes. It turns out that if a pie chart is instantiated
in a context in which the keys 'graph_mode', 'graph_measure',
and 'graph_groupbys' are present, that keys prevail over the
pie chart specification. This can produce a line chart for
instance. This fix corrects that situation.
A test has been added in a corresponding commit in enterprise
(historically, the pie chart widgets are tested in dashboard
views).
closesodoo/odoo#34234
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
- Create a leave type valid from June 1st
- Create a leave in May using the created leave type
Nothing prevents the user to do it.
It is because the constraint is implemented only if there is a validity
start and end date.
Fixes#32107
opw-2009800
closesodoo/odoo#34225
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Create a vendor receipt in a journal with a foreign currency with taxes
- Validate it
Bug:
A UserError was raised because it tried to create unbalanced entries
Technically: the debit and credit of the VAT account move line were not converted
in the currency of the of the voucher's company.
opw:2007760
closesodoo/odoo#34203
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
- Create a calendar event
- In debug mode, remove the responsible
The 'Avatar Undefined' string is displayed at the botton of the
responsibles' list.
Do no fetch an image for a falsy value (= falsy id)
opw-2010007
closesodoo/odoo#34215
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The search buttons visibility is saved in the local storage. Rev.
6448420 changed the API of the LocalStorage servive (by JSON
parsing the values), and didn't adapt the calls done for the
search buttons.
Closes#33833closesodoo/odoo#34206
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
The way to find a matching about structured communication is done by:
1 - making a filter to keep only numerical values.
2 - splitting the result into array.
3 - finding an intersect between the sets.
For example,
"Payment about +++123/456789+++ and +++987/654321+++" is matching "123456789 blablabla"?
1 - "123456789 987654321" is matching "123456789" ?
2 - ["123456789", "987654321"] is matching ["123456789"]
3 - YES because "123456789" intersects both sets.
This commit is about the check is always TRUE when both sets are empty.
In this specific case, the result must be FALSE.
-opw: 2008299closesodoo/odoo#34115
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Nicolas Martinelli