Before that, creating a tax without any repartition line with a company_id set in create() failed to create the default ones, because they did not receive the company they had to be created for (as 'company_id' was not passed to the default_get).
closesodoo/odoo#33617
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
The method _renderCreate in the ManualLineRenderer was executed before
the call to super finished. Which makes impossible to create a writeoff
in the reconciliation widget.
closesodoo/odoo#33582
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
- On the invoice pdf, if the invoice is in USD, we
need to specify conversion rate and amounts in AED.
Also, if it is between certain Gulf states, you need
to mention this on the invoice. 'Invoice' also
needs to replaced with 'Tax Invoice'.
- Taxes changed to 0% and 5% / AED symbol on currency
adapted to the real situation of UAE.
- A tax by state automatically adapted with the fiscal
positions in order to have the tax amounts correctly
split by state in the tax report.
opw-1931322
updated to 12.3 taxes (and l10n_ae_reports removed in
enterprise)
closesodoo/odoo#33474
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
In Sales > Order > SaleOrder > Print > Choose Document Layout > Save: when data is saved there is comes a traceback as write method is called directly on Save button.
(sale_management)
Hence write method should not be called and args passed returns an empty list.
- we defined dummy method to be called on save
Similarly, in TimeOff > Reporting > Report by Department > Print > Choose Document Layout > Save and Print : write_company_and_print_report method is called on Save and Print button
(hr_holidays)
-write method which is called inside write_company_and_print_report is removed as empty args list is passed.
reference is taken from- https://github.com/odoo/odoo/commit/1ced3bfca457ac50845637bcd42a8e53bd7f088d
opw:1973947
closesodoo/odoo#33454
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Basic Chart of Accounts and taxes for the Mongolian
accounting. Tags for a lot of reports in Enterprise.
A lot of different taxes are created to be able
to represent them in the vat report. Mongolians
are used to taxes included even for B2B.
Some fiscal positions are added e.g. to automatically
apply 0% for export.
We got a lot of input from our Mongolian partner
Baskhuu Lodoikhuu and colleagues from BumanIT LLC
opw-1946238
Adapted to taxes in 12.3
closesodoo/odoo#33399
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Due to forward port, _onKeydown was declared twice.
This commit should fix an issue in mobile with Android 4.4 where
it's not allowed to have two functions with the same name.
Original Commit: a3d98dae68closesodoo/odoo#33495
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Consider the following use case:
- Two taxes:
-A: price included, affect base of subsequent taxes, 10%
-B: 15%, regular
- Create an invoice with a line applying A, then B, for 110€. Post it
- The following move lines are generated:
- base: 100€
- tax A: 10€
- tax B: 16.5€
Before this fix, line "tax A" only had the tax tags of tax A. It should also receive the base tags from tax B, in order to affect its grid total correctly in the tax report.
Also, tax_base_amount field used to be computed, but its computation was too simple, and most of the time wrong when doing advanced use of taxes like the one we defined above. It is now not computed anymore, and directly takes its value from the compute_all's result.
closesodoo/odoo#33420
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The goal of this commit is the alignment of the total in List view.
before this commit, it shows the left side so that it looks weird.
After this commit total show below the related column.
Task: 1981893
closesodoo/odoo#33210
Signed-off-by: Jérome Maes (jem) <jem@openerp.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
- Activate cash basis
- Set a tax
Tax Due: Based on Payment
Include in Analytic Cost: true
- Create an invoice, add the tax and an analytic account on the invoice
line
- Validate and pay
The analytic account is correctly set on the tax line, but it is not set
on any of the cash basis entries.
Partial backport of 079a13a349.
opw-1971751
closesodoo/odoo#33236
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
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>
- Set a product barcode to a 8 letters value, e.g. 'AAAAAAAA'
- Print 'Product Barcode (PDF)' (or any other report containing the
barcode)
The barcode doesn't print.
All templates assume that:
- a 13 characters barcode is EAN13
- a 8 characters barcode is EAN8
But this assumption is too restrictive: one could want to generate
barcodes with such length without following the EAN13 or EAN8 structure.
We fall back on Code128 when the barcode generation fails.
Backport of 06cfdbaab8
opw-1981988
closesodoo/odoo#33240
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
There was a syntax improvment in the commit merged but it was not
intended to be unfinished.
fixes#33228
opw-1981839
closes#33239
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The selector used for finding the qty field is simply 'qty', which is useless
in most cases.
While there is actually no quantity input in a wishlist template, it could be
leveraged by extension modules.
Support for same markup as found in product page seems appropriate:
input[name="add_qty"]
closesodoo/odoo#33224
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
In 11.0 091c86c21 introduced the unselection of lines when line are
resequenced to solve some issue.
There seems to be a related issue in the following use case if:
- the one2many has a handle field
- the lines have same sequence (eg. adding 2 o2m lines on new record)
- there is an invalid o2m line (eg. empty line and required field)
- without blurring, a valid line is moved
then this happen:
- the sequence of lines are computed
- the invalid line is removed
- the computed sequence of lines are applied
=> this break next onchange, because we try to apply an onchange to data
that does not exist anymore (the invalid line).
With this changeset, the invalid lines are discarded before sequences
are computed so the computation is still correct before being applied.
Without the change, the added test fails with:
5. one onchange happens when lines are resequenced (expect: 3, res: 2)
7. one onchange happens when a line is added (expect: 4, res: 2)
8. onchange worked there is 2 lines (expect: 2, res: 1)
opw-1966589
closes#33591
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When paying an eCommerce order with an acquirer which doesn't
redirect (payment_flow: s2s) the "Pay Now" button is correctly
disabled after clicking it. This prevents a user from clicking it
multiple times and being charged multiple times.
When paying with an existing payment token however the button was not
disabled and the user gets no feedback his request is being
processed. Charging an existing payment token takes a while (~5
seconds with Authorize) and so it's possible users will hit the button
multiple times.
This disables the button when reusing an existing payment
token. Additionally it now uses the correct font awesome icon (fa-lock
instead of fa-plus-circle).
opw-1981064
closesodoo/odoo#33196
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Since f5625969be, web assets in survey module
was loaded twice when website (and website_survey) is installed.
Thoses web assets are now externalised in another template that is loaded
only if survey is installed without website installed.
Task ID : 1985977
PR #33218
Also linked to Master task - refactor survey
Task ID : 1930132
PR #32419
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Python2 uses byte strings by default and python3 text string, so adapt
the code communicating with blackbox to still only use bytestring.
Also raspbian image has been updated in posbox 17 to Raspbian 9
(stretch) so ifconfig command returns has different format output (
`ether {MAC address}` instead of `HWAddr {MAC address}`) so the way we
get the MAC address is changed.
opw-1981839
closes#33150
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.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>
ONLINE:
make an order, chose a customer, click on "invoice"
Make the payment, validate
Just **before** the request to download the pdf of the invoice
go OFFLINE
(to achieve this, just put a debugger before the do_action() fires, and kill the server)
Before this commit, the button validate on the payment screen stayed inactive forever
This was because the deferred representing the invoicing flow was still pending
After this commit, we handle the case to invite the waiter to print the invoice
from the backend
OPW 1972301
closesodoo/odoo#33188
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
There was 2 issues regarding delivery price when the delivery was set to fixed
price and free over a certain amount.
1. On /shop/payment step, such deliveries would have the fixed price shown on
the badge, even if the sale order amount exceed the free over threshold.
2. When clicking on a delivery carrier, it is supposed to compute all the SO
costs (delivery, taxes..) and display them.
The delivery price selector would try to get the 'badge.hidden' element
which never exists for fixed prices. Thus, it would not update the delivery
badge price.
Now:
1. If the free over threshold is met, we display 0$ instead of the fixed price
by calling `rate_shipment`.
Note that `rate_shipment` can't fail in case of a fixed rate (see method).
The only failing case is if the customer country does not match the delivery
allowed country, but such a flow is not possible as delivery shown during
cart payment are already filtered by allowed countries.
2. The delivery value returned after clicking on the carrier is correctly
updated on the badge.
Fixes#31502closesodoo/odoo#32938
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Putting *args and **kwargs confuses the function `odoo.api.split_context`.
This causes that a call to `search` via XMLRPC gets the wrong argument: takes
the first argument of ``args`` as the context.
Example which ignores the `count=True`::
```
api.call_kw(self.env['product.product'], 'search', (
[], False, False, None, True, {'lang': 'en_US'}
), {})
```
would ignore the `count=True` and use the wrong argument for context.
Issue introduced in commit 15ea753a.
Since:
`def search(self, model=None, *args, **kwargs)`
is equivalent to:
`def search(self, args, offset=0, limit=None, order=None, count=False):`
because the call to the super will anyway call the parent method, we can
change the method arguments.
note: this is only for [10.0,saas-14] where 15ea753a is.
closes#33147
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: Nicolas Lempereur <nle-odoo@users.noreply.github.com>
For now the SO made with an amount of 0, are not automatically velidated
as there are no transactions. To avoid this problem, we are calling
actionn_confirm on the order with amount 0.
closesodoo/odoo#33176
Signed-off-by: pimodoo <pimodoo@users.noreply.github.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>
The "from" of an email is expected to follow the regex
"name <address>(, name <address>)*".
We simply split the from on the commas "," and try to interpret each piece as a
(name, address) pair.
If a "from" contains a name that is not quoted, and contains special characters
before the comma, then we would try to encode that name into an email address,
and fail on a UnicodeEncodeError.
E.g. the following "🐧, <a@a.com>" would be parsed as [('', '🐧'),('', 'a@a.com')]
thus Odoo would crash on trying to use 🐧 as email address.
With this commit we would just mess up the name in these situations,
by ignoring failures.
opw 1923429closesodoo/odoo#33145
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
- Install `l10n_be_hr_payroll_fleet`
- Connect as admin
- Change demo user rights:
- Remove fleet (nothing, not user, not manager)
- Set employee Manager.
- Connect as demo
- On an employee, click the "Contracts" smart button.
- Try to create a contract.
Before this revision, access right issues were raised:
- Just after the create, as default values couldn't be computed,
- After the save as well, because of defaults and computed fields.
The real use case here is for our own sake: Dubai HR Officers
do not have access to Fleet as they do not have company cars,
but they can't create contracts for their own employees
without having access to fleet.
closesodoo/odoo#33120
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Olivier Colson