Modifying a source term in an XML/HTML translated field can lose translations
if the same term is translated in several languages.
closesodoo/odoo#29078
The other methods do test password length before verifying it, so even
if check_credentials() is not meant to be called directly, it's better
to keep it consistent with the alternatives.
Closes#29023
Suppose you have a workorder to create n units of product P,
using raw material R (suppose we use one for one, the following can be extended
to any number of raw materials and factors in a straightforward manner).
Produce j < n units of P. Next, update the quantity to produce to j < k < n.
Since any number m of units between j and n may already have been reserved,
in particular values such that m > k, the move will unreserve the material R.
However, while doing so it will unlink the move_lines, and lose the
quantity_done (j).
The newly created move lines have a quantity_done of zero by default.
Therefore, we store in a dictionary the quantities done for each move line,
and reset these values once the unreservation/reservation of k units is done.
opw 1911969
closesodoo/odoo#28990
Before this fix products in a pricelist would not be grouped when there
is a decimal value in the price.
This problem was caused by a trailing rounding error, for instance a
price of 29.90 could give a pricelist price of 29.900000000002. To solve
this we check if Math.round((price - pricelist-price)/currency-rounding)
gives 0 as a result, if so, the price is equal to the pricelist price
and the product can be grouped.
solves: https://github.com/odoo/odoo/issues/28521#issuecomment-443148920closesodoo/odoo#29185
When activating a filter on a list view,
the environment of the action contained a context with an orderedBy key
which was then used by every controller and model in the various
parallel flows, i.e. changing actions
After this commit, we prevent it by excluding the key when executing an action
OPW 1913190, 1914019
closesodoo/odoo#29186
Changing the journal of a reconcialiation model to a journal not
reconciliable resulted to the model not accessible from any
menu.
opw-1913079
closesodoo/odoo#29249
We now support version 0.12.5(.1), which is available for all recent Debian and Ubuntu versions,
and contains quite a few bug fixes. An up-to-date version of Odoo 10 or later is required, for
pixel-perfect compatibility with the result of 0.12.1.3.
See also the wiki for more info: https://github.com/odoo/odoo/wiki/Wkhtmltopdf
By this commit, in sales by channel report of product page we are able to show the quanity of product which is just in 'sale' and 'done' state.
Before this commit, the quantity of product included every state except 'cancel'.
This commit is related to issue: #27643closesodoo/odoo#28948
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
- Create 2 companies C1 and C2
- Do not share partners between companies
- Create a partner P1 in C1:
Name: PartnerA
AccountNumber: 1234
- Create a partner P2 in C2:
Name: PartnerA
AccountNumber: 1234
- Create an invoice in C2 for P2, validate and pay
- Add the fields `account_number` and `partner_name` to the bank
statement lines for convenience.
- Create a bank statement with a line:
Partner Name: PartnerA
Account Number: 1234
- Run the following query (on which no record rule is applied for bank
statement reconciliation):
```sql
SELECT
st_line.id AS id,
COALESCE(p1.id,p2.id,p3.id) AS partner_id,
p1.id AS p1,
p2.id AS p2,
p3.id AS p3
FROM account_bank_statement_line st_line
LEFT JOIN res_partner_bank bank ON bank.id = st_line.bank_account_id OR bank.acc_number = st_line.account_number
LEFT JOIN res_partner p1 ON st_line.partner_id=p1.id
LEFT JOIN res_partner p2 ON bank.partner_id=p2.id
LEFT JOIN res_partner p3 ON p3.name ILIKE st_line.partner_name
WHERE st_line.id IN (XX);
```
The result is:
| id | partner_id| p1| p2| p3|
|----------|-------------|--------|------|------|
| XX| P1| null| P1| P1|
| XX| P2| null| P2| P1|
P1 should not appear in any of the results. In some configuration, P1
will be selected for matching and will trigger an access error.
Commit 1fc0b08e14 introduced the record
rules for `p3`, but was wrongly set at the end of the query. We
introduce the rules for `p3` as well as `bank`, so the result is now:
| id | partner_id| p1| p2| p3|
|----------|-------------|--------|------|------|
| XX| P2| null| P2| null|
Which is the expected result.
Fixes#32954
opw-1974649
closesodoo/odoo#33245
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When the clickEverywhere js test is started with base only, the
web client opens the first app by default (see openFirstApp call in
web_client.js). Unfortunately, the test clicks immediately on the apps
menu and the client does not invalidate openFirstApp.
Then, when trying to click on a filter, it does not exists anymore and
leads to a timeout.
The present timeout should solve the problem without refactoring the web
client.
closesodoo/odoo#33339
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
When Odoo is stopped using CTRL+C on Windows, a Traceback is thrown
because the SIGXCPU signal does not exists on Windows.
With this commit, the check for SIGXCPU only occurs on supported
platforms.
Fixes#33311closesodoo/odoo#33333
Signed-off-by: Christophe Simonis <chs@odoo.com>
This commit aims to make unit tests pass when creating a new database
with only 'survey' installed.
The tour 'test_survey' was not loaded before reaching /survey/start,
causing tests to fail.
The js asset is now loaded within web.assets_common because the tour
should also work with the 'public' user. For this reason,
'web.assets_backend' is not a good fit.
Widget 'root.widget' was undefined too. Appropriate js file is now
loaded.
Closes#33330
Signed-off-by: Christophe Simonis <chs@odoo.com>
Before this revision, the public user of your website could be changed
upon saving the general settings if you added users in the public group.
Case:
- Install website
- Add a user in the "public" group,
with a login sorted alphabetically before "public", let's say "1public"
- Open the general settings and save directly
- Notice the public user of the website has been changed to "1public",
and it did not keep "public", while you haven't changed anything
in the settings.
That said, the current heuristic to find the public user of a company
might not be the best, as you could automatically find users in the group
public that you would not like to use as the public user of your website.
In master, maybe a field `public_user_id` could be added on
`res.company`, and the `user_id` of the website could become
a related of the company public user.
In addition, when `_get_public_user` creates a new public user,
it could link it to the company in `public_user_id` field.
closesodoo/odoo#33332
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
Steps to reproduce the bug:
- Create two storable products A and B
- Create a BOM for A with B as component and A as by product
- Set this BOM as "To manufacture"
- Create a MO for A and try to process it
Bug:
Ensure one error was raised by function check_finished_move_lots defined in module mrp
because the variable produce_move must be one record.
Now, it's not possible to create a MO for A if A has a BOM with A as by product.
opw:1974863
closesodoo/odoo#33280
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When creating a new crm lead from the kanban view, using the quick add
button, the default probability is the one of the first stage, and not
the one of the selected stage.
Now, the default probability is the one of the selected stage.
opw-1986047
closesodoo/odoo#33267
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Since the changes introduced in cdcdebc6cb,
the tax amounts were not showing in the Sale Details Report.
closesodoo/odoo#33007
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
In a web editor, add some text, select the text, add a link and
immediately discard the link modal. Traceback.
The traceback is a DOM `IndexSizeError`, that error is thrown when the
boundaries of a DOM Range (`document.createRange`) are outside of the
ranged elements. In this context, the error happens because the element
is empty and the range has an end bound set to the size of the selected
text.
Odoo wrap code does some text node split in order to attach the link
just on the selected text. If it correctly re-set the underlying
structure, it does not update the $(editable) structure used to restore
ranges.
opw-1981751
closesodoo/odoo#33257
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Creating a new database with only sale_stock installed will lead the
boot_tests.js test to fail.
That's because commit 033608eb11
introduces an implicit dependency on a sale_management tour. This seems
to be a mistake since sale_stock does not depend on sale_management.
The tour only makes sense if both sale_stock and sale_management are
installed though. That's why the additional steps will be run
conditionally.
After this commit, the extra steps will only be run when sale_management
is installed.
Technically, this is done by checking whether odoo._modules contains
sale_management.
opw-1964469
closes#33275
Signed-off-by: Christophe Simonis <chs@odoo.com>
- specify the correct separators on the language
- add the address format
- add street addres format for croatia
closesodoo/odoo#33205
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
avoid to get journal_entry_ids, to avoid pushing those ids in cache and
having them read uselessly when accessing an account.move.line
recordset.
Use search and search_read instead of ORM __get__
closesodoo/odoo#33192
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Co-authored-by: william-andre <wan@odoo.com>
Commit c7773f9f introduced a duplicated term to the file .pot, which
causes the following error when trying to re-load translations:
```
ON CONFLICT DO UPDATE command cannot affect row a second time
HINT: Ensure that no rows proposed for insertion within the same
command have duplicate constrained values.
```
This commit removes on eof the duplicates, leaving only the valid one.
In addition, field string is modified to match the one defined at the
`website_sale` module, to prevent this from happening again, as had also
in 6af6da5c.
closesodoo/odoo#33223
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When a new request of leave is created, some fields are computed to
calculate if it's possible or not, to take the leave
(virtual_remaining_leaves, leaves_taken, remaining_leaves and
max_leaves).
These fields are computed using the fields :
allocation : hr_leave_allocation.number_of_days.
and request : hr_leave.number_of_days.
When a leave type is in hours, both of these fields are calculated
differently:
allocation: The allocation field is calculated dividing the number of
hours registered by the user per the average hour per working day.
(https://github.com/odoo/odoo/blob/d809b476819968837b61bdd78fbf101caac73adc/addons/hr_holidays/models/hr_leave_allocation.py#L236)
request : The request field is calculated by finding the real number of
requested days.
(https://github.com/odoo/odoo/blob/d809b476819968837b61bdd78fbf101caac73adc/addons/hr_holidays/models/hr_leave.py#L360)
If in the company each day have different working hour, then the number
of days calculated with the average hours didn't represent the real
number of days that the employee can take. This issue can avoid the
employee to take a leave even if he has the correct number of hours to
take it.
Now, the fields (virtual_remaining_leaves, leaves_taken,
remaining_leaves and max_leaves) are calculated using either the days
fields or the hours fields depending on the leave type.
opw-1972133
closesodoo/odoo#33244
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When a leave type is in hours, before this commit, in the allocation
list the allocation is shown in days. The problem is that the number of
days its calculated with the average hour per day. If in the company
each day have different working hour, then the number of days calculated
with the average didn't represent the actual number of days that the
employee can take.
Now, in the allocation list, the allocation is shown either with days or
hours depending on the leave type.
opw-1972133
The `_search` is override in `calendar.event` to return both ids and
virtual ids of recurrent events. Calling `.get_recurrent_ids` after the
search is wrong.
The entire request has been copied from the original
`_find_allowed_model_wise` function defined in `mail.message` to ensure
his correctness.
The purpose here is to ensure every virtual event id is mapped to the
real event id so the original function doesn't throw KeyErrors for
virtual ids.
opw-1972563
closesodoo/odoo#33246
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
- Install the 'Maintenance' app
- Create a maintenance request, set a day and a duration of 6 hours
- Go the calendar view, month mode
- Move the maintenance request from one day to another
The duration is changed with a non-sense value.
In month mode, the hours are not represented in the calendar so it is
not possible to compute the `date_delay`. Moreover, when a record is
moved from one date to another (`_onDropRecord`) in month mode, there is
actually no point recomputing the duration; the `date_start` is enough.
Note that `date_delay` is used (at the time of writing) in 2 views and
absolutely not tested.
opw-1984637
closesodoo/odoo#33193
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Have sections order lines on each Sale Order
Have multiple Sale Orders on which the action "invoice order" is triggered
(to make one invoice for all of them)
Before this commit, the real invoice lines were not under their respective
section line
This was because we kept the sequence of the order line when making the order line
which makes little sense in a case where we merge the orders
After this commit, the invoice lines are under their respective section
OPW 1985080
closesodoo/odoo#33219
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The email_compose_message_wizard_form takes a default_composition_mode.
If it is 'mass_mail', the used mail template is not rendered.
Since this is basically unreadable for a normal user, this can be confusing.
Note that this is even the case if the mail is being sent on only one record.
We use the 'comment' composition mode if there is only one target record so that
the template is rendered in that case.
opw 1984381
closesodoo/odoo#33173
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Make a CRM lead, assign it to a portal user
Have an automated action which add followers on create and write
From the portal, edit the lead
Before this commit, it crashed because a portal user doesn't have access to ir.model
(4a18d5744e)
After this commit, the flow works, because we use the stored model name on the action
instead of trying to read ir.model
OPW 1985570
closesodoo/odoo#33211
Signed-off-by: Christophe Simonis <chs@odoo.com>
Steps to reproduce the bug:
- Create a project called "R&D"
- Create two service products P1 and P2 with 'Timesheets on tasks' and
'Create a task in an existing project' for project 'R&D'
- Create a SO1 with 5 P1 and SO2 with 10 P2 and confirm SO1 and SO2
- Deliver 1 hour for P1 and 2 hours for P2 (with timesheets)
- Click on "Project Overview" button
Bug:
The remaining hours for SO1 was 12 hours instead of 4 hours and the remaining hours
for SO2 was 12 hours instead of 8 hours
opw:1981903
closesodoo/odoo#33183
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Following f4fbaf1efa
which changes the label/checkbox structure into:
```
<div class="custom-control custom-checkbox">
<input type="checkbox" class="custom-control-input" id="customCheck1">
<label class="custom-control-label" for="customCheck1">...</label>
</div>
```
So, before this commit, there may have been multiple input with the same Id.
The consequence is that, when clicking on a label, the browser would take the first Id it found
which was erroneous, because all checkboxes in Favorites menu had the same Id
In reality, the use case goes as:
- open a x2m,
- search more
- Favorites > Save current search
> click on one the two checkboxes
> The dropdown closed, without checking the box
After this commit, when clicking on the checkbox in the favorites menu
the checkbox is toggled and the dropdown stays. Also, the checkboxed have now unique ids
OPW 1974587
closesodoo/odoo#33032
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This reverts commit 9c4b52000f.
The fix of opw-1974599 is wrong. As the fix was fixing a corner case, it
is better to revert this one as it is breaking all recurrent events.
opw-1985498
opw-1985552
closesodoo/odoo#33206
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
* order of parameters to translator swapped
* context['meta'] always set, defaulting to None if the document has no
metadata
* [3.0 prep] modifying script_files deprecated, use add_javascript /
add_js_file
* remove deprecated call to l_ (which was useless anyway as the documentation
is not translated)
Fixes#33107closesodoo/odoo#33187
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The status link was duplicated, making it skipped during rendering
Use correct indent
closesodoo/odoo#32843
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Currenly in the digest when you send the template, tips are not being seen.
The reason for this is, we are getting tips from the context but we dont have it in the context.
Instead, we are fetching the tips by calling the compute_tips method and assigning it to 'tips'.
Hence, this commit will remove the usage of context to get the tips as we are getting it
from the method and not from the context.
Task ID: #1918364closesodoo/odoo#33186
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This rev. disables Popper.js 3d transformation for positioning
bootstrap dropdowns in navbar, as this transformation causes a
rendering issue on webkit-based browsers (the text in the dropdown
is blurry).
See https://github.com/twbs/bootstrap/issues/23590
Note that it has already been disabled for the other menu dropdowns
(user menu, debug menu) by rev. 5373db1.
Another solution would have been to override the default value in
our bootstrap.js extension file, but for dropdowns that aren't in
the navbar, the dynamic positionning could be interesting.
Fixes#33096closesodoo/odoo#33174
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Configure google to be synchronized with Odoo, create a contact with a
wrong email address (I used `foo@.test.`), create an event in the
calendar, add the contact as attendee, sync with google. Traceback.
The traceback is a `request.exception.HTTPError` reraise by
`_do_request` in the `google.service` model on several HTTP errors, 400
amoung them. The real error is "Invalid attendee email." but the
information is lost in the error message.
The error hanlding has been rethink so it raise a user friendly error
via the UserError modal with just the error message sent by the Google
API. The logged error has been rethink to pretty print both the request
and the response.
opw-1974295
closesodoo/odoo#33058
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Arabic customers are complaining the Lato font is very odd looking for
Arabic scripts. Furthermore, since #32312 Noto is used as the prefered
font to display arabic scripts.
The classes are used by the "Company Tagline" configured along with the
template in use in the general settings.
opw-1946109
closesodoo/odoo#33141
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Open a record having a chatter, edit a field, add an attachment, leave
the page. The discard warning popup in not shown.
When an attachment is added, it reloads the record to fetch the new
`attachment_message_count`. Reloading the view was discarding the
changes because the `keepChanges` option was not set and defaults to
`false`. The changes were discarded thus the internal `_isDirty` flag
evaluated to `false` thus the popup was not shown as nothing would have
been saved.
The option was set in another `attachment_message_count` reload already,
in `chatter.js@_openComposer`.
opw-1974147
closesodoo/odoo#33180
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Some distributions still bundle chardet 2.3, which have some guessing
divergences / incompatibilities with python (resolved in 3.x):
1. UTF-{16,32} with BOM is guessed as LE/BE, which when used to decode
the string doesn't strip out the BOM. Handle this by checking if
the BOM is present and converting the encoding name to the
non-marked version in that case.
2. The ISO-8859-1 test string is guessed as ISO-8859-2 (TBF the
decoding does make some sense). Allow multiple targets/guesses to
"fix" that.
closesodoo/odoo#33179
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The follower button had a useless fixed width which made it overlap with
other buttons.
Fixesodoo/odoo#29387Closesodoo/odoo#33063
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Raphael Collet