The VAT declaration produces an error when uploaded to the official
website. Although the structure is correct, the "Representative" and the
"Declarant" contain the same information, which is not consistent.
opw-702066
Both store triggers on reconcile_ref are triggered by the same condition,
but seen on 2 tables different, but they always happen together, so no
need for both.
On regular Odoo, the only problem is the performance: the write operation
is performed twice, but on a system with connector or other parallelization
technology, this provokes lot of concurrency problems.
With the previous condition, the `final_date`
was not recomputed when the number of repetitions
(count) was changed alone, without changing `recurrency`
(nor with other fields, such as start/stop date)
This revision makes sure to recompute the `final_date` when
there is a change in the number of repetitions without
changing the `recurrency` fields, when the event is recurrency
and the end type is `count`
opw-703812
This commit fix wrong grouping when we format price via price_to_str.
where '[3,0]' was interpreted as string and not array in intersperse.
Thousand separator was duplicated ",,,320.00" e.g.
This commit fix also product page where amount for variant was formatted
js side before that RPC translation (website.ready() defered) was resolved.
'/website/translations' is only called when user have rights to edit page.
So a standard user didn't call it and l10n is not initialized.
After an update, now we format the amount with the l10n value.
To stay retro compatible, if l10n is not initialized (value = [])
we use [] for grouping as 'fallback value'.
To fix decimal precision you need to update the template product_price.
To fix the grouping, you need to update the website.layout
To fix the decimal separator, (and previous fix), you just need to pull the JS
This commit is related to #1103, #11553, #14772, #14874, ...
And fix the previous fix odoo/odoo@1f10ef8055
It should also fix (by side-effect) the translation JS for user without editor
right.
Already fixed in V9 - don't forward this commit...
When reading customized views from our dashbord in reporting,
the measures selected in the customized views were not taken into
account. It happened when the customized view was build from a report.
opw:698105
When syncrhonizing an allday event while being in a negative timezone
e.g. Dec 22 in US/Eastner (-5:00)
The event was synchronized the day before
e.g. Dec 21
because `context_timestamp` of `start date-time-` was used,
and then the time was removed to have the date of the all day event
e.g. 2016-12-22 00:00:00 converted to 2016-12-21 19:00:00 and then the time
removed 2016-12-21.
Instead of using the `start_datetime`, we now use the start
date which stores only the date, without timezone information
(and this is what you would like in the case of an all day event).
opw-697202
While choosing a start/stop datetime in a timezone hour
were the UTC value is within the next day,
e.g.
Start time Dec 22 20:00 in US/Eastner (UTC -5:00)
Therefore, start time Dec 23 01:00 in UTC
Checking the "all day" box made the start time set to
Dec 23 instead of what the user expected, Dec 22.
This is because the onchange simply took the UTC datetime
(Dec 23 01:00) from which it removed the time (Dec 23).
This revision make sure to remove the time from the
user timezoned datetime instead, so the day set
remain the same day than what was set in the datetime.
opw-702065
Event with interval > 1 was not correctly computed.
This patch doesn't fix existing event but only the new one created after this fix.
Event 1/1/2015 repeat every 3 months, 6 times
Before this commit : end recurrency = 1/1/2015 + 6 * 1 month
After this commit: end recurrency = 1/1/2015 + 6 * 1 month * 3 (interval)
This commit closes#14332
Fix datetime where the return of rrule is sometime a list,
sometime a set according to the datetime version.
list(set) == list(list) and works in both cases.
Similar fix: #9f09c62
Do these steps:
1. Create a partner.
2. Grant him portal access through *Actions > Portal Access Management*.
3. Delete the created user.
4. Delete the partner.
You will get this error:
```
Odoo Warning - Validation Error
The operation cannot be completed, probably due to the following:
- deletion: you may be trying to delete a record while other records still reference it
- creation/update: a mandatory field is not correctly set
[object with reference: Portal User Config - portal.wizard.user]
```
This happens because the wizard (which is a transient model) does not let the partner to be deleted.
With this patch, we avoid that bug.
Closes#12608
As the number of holidays are float, we may get a flloating point error when
comparing and having -0.0000000001 instead of 0 for the number of remaining
leaves, making the test fail.
Closes#12809Fixes#14643
The requirement for somebody to choose a ticket product should be that it is an
event, not that it has an event type attached, mostly when `event_type_id` is
not a required field.
The event has been improved in upper version but as this field is only
informative, relaxing a bit the domain.
Closes#12475
When sending an email via the mail.compose wizard, the selected partners are
stored in the context (`active_ids`).
If the composed message is saved (button "save template"), the context is lost
in the _reopen action.
The active_ids content of the new context is the id of the newly created mail
template and is used as the id of a res.partner (sending the email to a
different contact).
Keep the context during the reopen to avoid losing active_ids.
Closes#11947
The account move line created for a tax must have the right account_analytic_id
according CONDITION.
CONDITION(inspired from function compute defined on model "account.invoice.tax")
if the tax is for an "in_invoice" or an "out_invoice" => tax_code = 'tax_code_id'
=> the account_analytic_id of the tax must be set to 'account_analytic_collected_id'
if the tax is for an "out_refund" or an "in_refund" => tax_code = 'ref_tax_code_id'
=> the account_analytic_id of the tax must be set to 'account_analytic_paid_id'
note:forward-port upto saas-6
opw:694821
Declaring the keyword argument `context` in an API v7 `orm.browse_record` can
lead to mixed API v7/v8 inheritance bugs (`context` will be treated as a
function parameter instead of being injected in `self.env.context`). As the
context is already propagated in line 953, we can safely remove it from line
971.
Closes#13115
When the user name entered hasn't an email specified the error message wasn't
displayed in the reset view.
The error message was in e.name, not e.message
Due to the following revision:
456d7b38f1
The company on the order line was not assigned
when creating a new line in an existing sale order.
The company was correctly assigned when you created
the order line with the order, and when changing the company
of the order, but not when adding a new line on an existing order.
This new trigger repairs this regression.
Due to the following revision:
295b96c0b3
The company on the version and items was not assigned
when creating a new pricelist version on an existing
pricelist.
They were if you changed the company of the pricelist,
thanks to the triggers added in the above revision,
but not when they have just been created in the pricelist.
These new triggers repairs this regression. It also handle
changing the `pricelist_id` of a version (this is doable through
the "Sales > Configuration > Pricelists > Pricelist Versions" menu).
Fixes#14631
The website `default_lang_id` was not required,
while the algorithm choosing the website language
expects it to be required.
This solves the below issue, when your browser language is en_US:
- add a second language to the website (e.g. fr_BE or es_VE),
- in the website settings, remove English from the languages
- in the website settings, unset the default language
- try to go on the website
You will have a crash:
```
File "/home/odoo/src/odoo/saas-11/addons/website/models/ir_http.py", line 193, in _dispatch
resp.set_cookie('website_lang', request.lang)
File "/usr/lib/python2.7/dist-packages/werkzeug/wrappers.py", line 992, in set_cookie
self.charset))
File "/usr/lib/python2.7/dist-packages/werkzeug/http.py", line 905, in dump_cookie
value = to_bytes(value, charset)
File "/usr/lib/python2.7/dist-packages/werkzeug/_compat.py", line 106, in to_bytes
raise TypeError('Expected bytes')
TypeError: Expected bytes
```
This is because the `request.lang` is set to `False`
because of the below algorithm in `ir_http.py`:
```
nearest_lang = not func and self.get_nearest_lang(path[1])
url_lang = nearest_lang and path[1]
preferred_lang = ((cook_lang if cook_lang in langs else False)
or self.get_nearest_lang(request.lang)
or request.website.default_lang_code)
is_a_bot = self.is_a_bot()
request.lang = request.context['lang'] = nearest_lang or preferred_lang
```
`nearest_lang` is `False`, because there is no nearest language
available for the browser lang (`en_US`)
`cook_lang` is `False` for users who never went on the website
`request.website.default_lang_code`, which is the last feedback,
is also `False` because you removed the default language
in the website settings.
opw-695621
The deleted code put the same picking_type_id for all companies.
The function _get_picking_in returns the right default picking_type_id
according to the company.
Steps to reproduce:
-stock.warehouse0 is on company A.
-Define another company B with its own warehouse.
-Update the purchase module -> a new default value for picking_type_id on purchase
order for company B is created wtih the value of company A
-Create a purchase order on company B, Odoo tries to get the picking_type_id from company A.
If user doesn't have any rights on company A, it occurs a security warning.
Otherwise the purchase order is linked to a picking operation of another company.
opw:694059
In `action_cancel` method below, the date_cancel is set when the linked invoice
is canceled.
When the canceled invoiced was reset to draft, the date_cancel was not removed.
This change makes sense as the state of the membership line is changed from
`cancel` to `waiting` when the invoice is reset to draft.
Closes#14313
Before this commit, amount updated from ajax request don't respect currency format.
Eg: 1.200,000 => 1200.00
Now we use the grouping/thousand separator/decimal separator from l10n,
and if class decimal_precision is defined in dom, we use it. (format=0.001)
This commits closes: #11553
This commits is related to #1103
When processing a partial reconciliation in a foreign currency, a
currency exchange difference might be generated during the
reconciliation process (see OPW for a detailed use case).
This prevents the user to process the reconciliation since he will get
the error: 'You have to provide an account for the write off/exchange
difference entry.'
The fix is to use the company-related foreign echange gain and loss
accounts automatically to book this difference.
opw-687975
When changing the company of a sales order,
the change was not propagated to the related, stored, company field
of its sale order lines
These triggers makes that happen.
opw-694683
When changing the company of a pricelist,
the change was not propagated to the related, stored, company fields
of the `product.pricelist.version` and the `product.pricelist.item`
These triggers makes that happen.
opw-694683
Previous implementation did not allow the user to search for pages 'name'
but only on the slugified name.
Now we slugify the needles before to find a match.
1. Create a new page: 'The new'
2. add a link on your website and try to find this page...
- Before this commit, the only ways was to type 'the-new'
- After this commit 'the new', 'The new', 'The-new', ... will match
This commit closes#10771
Without this patch, when a product was added to cart, if this addon
was installed, it always landed in English in the SO.
This happened because the context, containing the current language,
was being aborted here (`context=None` instead of `context=context`).
This commit closes#14340
It seems Paypal does not always send the same responses on auto-return
even when PDT is off. Although not reproducible on a Paypal sandbox,
sometimes the system auto-return to /payment/paypal/dpn without any
meaningful POST data. This seems to only happen with new accounts
that use the 'Hermes' web application of Paypal.
The correct thing to do would be to add a new field on the paypal
payment provider for PDT token and make the PDT flow available
to users; but this is a stable branch and this fix is already
sufficiently delicate. This shall be done in master though.
From this revision on, users can then activate PDT on their paypal
account, set the PDT token as an ir.config_parameter value (WITH
GROUP RESTRICTION SET TO ADMIN/SETTINGS GROUP!!!) and the system
will process these requests correctly.
Instead of hardcoding the IN & OUT endpoint
addresses for the ESC/POS printers, we now
attempt to auto-detect them.
This should increase compatibility with many
compatible thermal printers that are simply
using a different address, such as the
- STMicroelectronics POS58 Printer USB
- HU HAI SUNCSW Receipt Printer Co.,Ltd. Gprinter USB Printer
Fixes#12890
Before, it did a search to see if the package existed,
but the only thing it needs to do is see if the package
on the pack operation corresponds to that of the quant. (no need to check children also)
There is a test added:
A picking with 120 pieces incoming, 120 in pack 1, 80 in pack2
When we deliver those in a picking out, with product pack operations: (by taking them out of the pack)
120 from pack 1 and 80 from pack2,
we should only have 2 quants and links between moves in the end
And before, it generated 3 because it matched the wrong quants and made the wrong links.
opw 693760 closes#13836
This commit fixes the driver to respect the new device
registration mechanism via hw_proxy.rs232_devices.
It also refactors the code to more easily support multiple
scale protocols, and introduces support for the ADAM Equipment
AZExtra scale protocol. (Might be compatible with other ADAM
Equipment scales)
Support for th AZExtra scale is experimental at the moment,
especially given two annoying problems with this model:
- they do not support proper probing (stays mute until a
non-zero weight is measured), so they have to be probed
last and *assumed* to work
- the scale beeps when a read attempt is made and the
weight is not stable yet, or the weight has been already
read previously. This constant beeping during operation
is mitigated by extra delays between readings, but might
still prove to be a major issue for supporting this scale.
RS-232 drivers now need to register any device
they are handling in the hw_proxy.rs232_devices map.
This will prevent other drivers from probing them,
possibly messing up with the device.
Any update to rs232_devices must be done while holding
the hw_proxy.rs232_lock.
The hw_scale driver will be updated to use this mechanism
in the next commit, that will also handle a new RS-232
scale protocol.
- ngrok download URL has changed
- default kernel for raspbian image has changed and needs to match
- remove pre-existing git checkout to avoid conflicting
- wait a few seconds after setting up loop dev with kpartx to access image
contents - sometimes required to let the device appear in /dev
The company currency is USD, the invoice currency is EUR.
- Create an invoice in EUR, set an invoice date
- Compute the taxes (click on "update" button)
- Change the exchange rate between EUR and USD
- Validate the invoice
At validation, the tax lines are not recomputed. Therefore, the tax
amounts, are still converted in the company currency using the old
rates. On the other hands, the other account move lines will have the
appropriate new rate.
Closes#14024
opw-692430
The company currency is USD, the invoice currency is EUR.
- Create an invoice in EUR, set an invoice date
- Compute the taxes (click on "update" button)
- Change the exchange rate between EUR and USD
- Validate the invoice
At validation, the tax amounts are not recomputed. Therefore, they are
still converted in the company currency using the old rate.
Closes#14024
opw-692430
When an asset is set as Prorata Temporis, with a one month period, the
first depreciation amount is computed on the basis of the remaining days
in the purchase year. This doesn't make sense for a monthly
depreciation.
This commit makes the distinction between a monthly and a yearly
depreciation. In the case of a monthly depreciation, the remaining days
in the purchase month are taken into account.
opw-690034
Steps to reproduce :
1. Create a new customer
2. Create an invoice with an amount of 50.- for this new customer and validate it
3. Create a refund with an amount of 70.- for the same customer and validate it
4. Create a Customer Payment for this customer and validate it. The Invoice will be paid with 50.- of the refund. 20.- are still on residual in the refund.
5. Create a new invoice with an amount of 50.- for the same customer.
6. Create a new Customer Payment for the same Customer and validate it.
The Full Reconcile Boolean stays checked inspite of "Open Balance" of Refund amount is less than the Invoice amount.
After the fix:
Full Reconciliation Boolean doesn't get checked and Allocation amount on invoice journal item line should be same
as Open balance of the Refund Journal Item. So Invoice stays open with Balance amount.
opw:691577
Depending on the version of dateutil, rule._bynweekday can either be
a tuple or a set (see https://github.com/dateutil/dateutil/pull/54), which,
in the case of a set, breaks the access by index (see related issue:
https://github.com/dateutil/dateutil/issues/24).
By casting it into a list, we make sure that we can access [0] in both case.
Credits to jke ; closes opw-690761.
Underscore method _.each expects an array like object when a "length"
property is present.
This was an issue with a record having a numeric "length" field set to a
non-negative value. When changing a line the change would not appear on
blur.
This issue was fixed with 0e664c9e9 but introduced back with f0e331e00.
opw-691070
This revert the fix made on 7bdd4de and replace it with a proper one that do create an account entry from stock_input to stock_output on a dropship move. That way, we avoid the manual change of account on supplier invoice. See the whole discussion on odoo#12687
Before this commit, the inventory by lot/pack/serial/... was only visible
if you switch quickly between res_config and adjustment inventory... once
the vaccumn clean the osv memory, the options was ignored.
Same issue with the _get_string_qty_information function.
Like in Invoices Analysis, the expenses must be expressed in the currency
of the company. In this way, it makes sens to sum them to compute the total.
opw:689760
when extending these methods with the new api, the context is a frozendict
so we need to copy before mutating.
this patch was made by searching for key addition to context and calls to the
update() method on the 8.0 addons, and checking if a copy was made before in
the method.
Most people install the im_livechat module and expect it
to be enabled automatically on their website.
When it doesn't work they try to use the integration JS
code and add it to their website layout, which does not
work as expected.
Setting it as auto-installed solves the issue.
An issue occurs in the following situation:
- Define a currency exchange rate at day 1 and day 2
- Create an invoice at day 1, and calculate the taxes. Do not set an
invoice date!
- Validate the invoice at day 2
The exchange rate for taxes is the rate at day 1, while the exchange
rate for other amounts is the rate at day 2.
There is actually no way to know what was the rate applied for the
taxes at invoice validation. There are two solutions:
- recompute the taxes at validation
- force the user to set an invoice date and recompute manually the
taxes
The first solution might have unexpected effects, therefore the second
solution is applied.
Fixes#13473
opw-688517
It wasn't possible to cancel a purchase order
within the state "Waiting for Approval", despite
the fact the button cancel is displayed.
Clicking on the cancel button just did nothing.
This is now properly working, thanks to the additional
path added by this revision, between the workflow states
`CheckForApproval` and `cancel`.
opw-688685
Also restrict XML data attribute evaluation context
even for real module data files. This will prevent
accidentally depending on context parameters that
would not be available inside base_import_module.
When receiving new mail (not replies) to an alias we should not take
case into account.
This also homogenize the treatment of local parts. For instance, lines
967 and 980 convert the local part to lower case to avoid
case-sensitivity issues.
Also `mail_alias` normalizes alias names by lowering case and finding,
if necessary to make it unique, a suffix to alias name provided.
From RFC 5321, section 2.4:
> Exploiting the case sensitivity of mailbox local-parts impedes
> interoperability and is discouraged
Closes#334Closes#13037
encode the filter in utf-8
This prevents a UnicodeDecode error in python-ldap when the
filter contains non ascii characters.
opw-682783
closes#10899closes#12710
When we are on the page:
/blog/myblog-1/page/2
the link to page 3 is:
/blog/myblog-1/page/3
So we need to give /blog/our-blog-1 as source url of pager.
Previously in this instance, since 4faed0b7 the page 3 url
in this scenario would erroneously be:
/blog/myblog-1/page/2/page/3
opw-688681
If the title was 'true' or 'false', the export failed, because we are tying to
concat bool and str. TypeError: cannot concatenate 'str' and 'bool' objects
How to reproduce, install sale, be sure to have one order with delivered = True
In Reporting / Sale analysis, add a group by 'shipped' filed to have 'true' as
title.
This commit closes issue odoo/odoo#13425
Currently, when rendering a list view cell with a many2many we would
empty the list of ids, and fill it again once a name_get is resolved.
But in some instance, the code could use the data when it has been
emptied out.
For example, if we set the tax_id field (inside the order_line list view
inside the sale.order form view) as requred, if we modify the order line
and save directly (without clicking outside of the list view) we can get
an incorrect error saying that the "Order Line" is not valid.
It has been reproduced when saving with CTRL + SHIFT + S on google
chrome and firefox, and there have been reports that for some
configuration it also happen when clicking on the "Save" button.
This commit change the behaviour so the value is kept whilst the name_get
is ongoing, and just use a default "false" value for the name during this
interval.
closes#13478
opw-668067
Although we have been reluctant to perform this change, a specific
use case can cause customers to be redirect to the Odoo DPN url
with a GET request.
This happens when a Paypal Merchant account has the feature Guest
Checkout active; in that case, a customer can pay without having
a Paypal account (using only his credit card) and will *not* be
subjected to auto-return; as detailed here:
https://www.sandbox.paypal.com/be/cgi-bin/webscr?cmd=p/pop/help-account-optional
Request coming from that payment flow will always trigger a GET
request, causing the customer to be welcomed by a
405 - Method Not allowed
error on the Odoo server. The payment is normally correctly processed
through IPN, so this does not normally causes loss of data; however
this is not a nice way to welcome back your customer right after
they pay you.
Until 9.0 our psycopg2 DSN connection strings do not allow having
spaces within the db name, and passing some can cause duplicate
registries to be loaded.
Stripping spaces is a simple workaround until we actually support
spaces within db names.
Fixes#13078
OPW: 684742
When using dropship+anglo-saxon+perpetual valuation, there is no journal move for the delivery to debit outgoing inventory (since the goods don't transit by an internal stock) but the sale does credit it so there was a build up in the holding account that has to be moved out manually. This was also reported in #12687.
The solution implemented is to check if the invoice line is related to sale order lines having one of its procurement_ids with a purchase_line_id set. If yes, it means that it is a confirmed dropship and in that case we don't call to super (we don't create the cost of sale line).
That means that:
* If the procurement is in exception at the customer invoice time, the behavior will be as it is currently, but it's fine as you don't know how the procurement will be solved, and it'll be only at the beginning (once the config is done it shouldn't go in exception anymore). People will have to manually fix those amounts with a miscellaneous operation.
* users in anglo saxon mode should not use the 'stock interim account (received)' on supplier invoices for dropshipped goods, but rather use the COGS directly (sounds to me logical, and that's actually why I wouldn't go for the solution to create the stock move entries every time even for the dropshipped goods. That, and the fact that it would pollute the accounting with useless moves)
When the statusbar is clicked, a `debounce` function prevents a
doucle-click, and therefore making several `write` calls. On some status
bars, clicking doesn't work anymore.
The reason is because, in some mysterious cases, the event is propagated
to the parent. The `currentTarget` is not the `li` element, but the
parent `ul`. By setting the `immediate` argument to `true` (execute the
first function instead of the last), this solves the issue.
In psql, use LIMIT and OFFSET together without a fully specified and uniq sort order
will generate unexpected behaviour.
Eg:
> id id_dept name
> -------------------
> 1 1 Tom
> 2 1 Mike
> 3 2 Meggie
> 4 2 Marge
> 5 3 Bart
> 6 3 Lisa
> using LIMITed selects like:
> SELECT * FROM employee ORDER BY id_dept LIMIT 3
> SELECT * FROM employee ORDER BY id_dept LIMIT 3 OFFSET 3
> SELECT * FROM employee ORDER BY id_dept LIMIT 3 OFFSET 6
> You can have some result missings from the 3 requests, and others duplicated.
> Because id_dept is not a uniq order.
opw-686639
note: backport of saas-12 4dce8616
When a pie chart has no grouping selected, the label was "undefined" (the
javascript variable). Replace by the already translated string "Undefined".
Fixes#13288
This commit avoid a traceback when you open the form account_invoice_line
for a supllier invoice without having installed purchase.
The fields_view_get method add domain with purchase_ok field, but this
field can be missing on the model product.template because purchase is not
a dependence of account.
Invalid field 'purchase_ok' in leaf "<osv.ExtendedLeaf:
('purchase_ok', '=', True) on product_product
In stable version, the best fix found, is to remove the domain.
But we need to fix it in master, moving this field from purchase module to
product module. (odoo/odoo##13271)
This commit closes#13268 and closes#315 for stable version.
Todo: merge odoo/odoo#13271 in master (@qdp-odoo agreement)
Go to a URL such as `/blog/our-news-1?date_begin=2015-01-01`
Now click on page 2.
Without this patch you will go to `/blog/our-news-1?date_begin=2015-01-01/page/2`.
With this patch, you will go to `/blog/our-news-1/page/2?date_begin=2015-01-01`.
This commit closes#13206
In purchase, a special key is set in the context to simplify the name
of the picking type: instead of the normal name, only the name of the
warehouse is used. This is problematic if more than one incoming picking
type exists for a given warehouse, as it prevents you from being able to
differentiate them. Asking users to modify the view to remove the
context key seem a bit too much to ask for something that should be
simple.
It is my understanding that this was implemented only for cosmetic
reasons, but I am willing to assume that having to select
"YourCompany: Delivery Orders" instead of simply
"YourCompany" for people who only have one picking type should not
be too disruptive or obscure.
opw-685751
Inspired from e2d16ea
When cancelling a voucher from a customer payment receipt,
the voucher lines linked to the deleted account move lines
have to be updated by clicking on button "unreconcile".
opw:683258
When double-clicking on the statusbar widget, two calls to write are
performed. This can cause unwanted behavior, and when the `write` method
takes a lot of time to process, it's not possible to prevent it
server-side.
Courtesy of @gurneyalex and @aab-odoo
Closes#13134
opw-686025
FORWARD-PORT UP TO SAAS-6!
Inspired from e2d16ea04a
When cancelling a voucher from a customer payment receipt,
the voucher lines linked to the deleted account move lines
have to be updated by clicking on button "unreconcile".
opw:683258
When a user try to create a new page info, he is redirected
to the /page/info because the xmlid already exists...
The problem is that this view need to be rendered via the
controller /website/info which gives some extra values (version, ...)
The fix for v8 is to redirect /page/info to /website/info.
In V9, the behavior is changed and one page info-1 will be created.
But this fix is also required for direct access to /page/info.
To do in master: maybe use another xml_id that this basic name 'info'?
This commit fix issue #8022
When an internal move is partially delivered, name of the backorder is
'False'. This also occurs if an internal move is copied.
This is because there is not sequence for code 'stock.picking.internal',
but there is one for 'stock.picking'.
opw-683725
If you create a picking, with an owner, for qty x, and confirm it.
Next transfer x+1, it will raise a traceback 'cannot adapt res.partner'
Now, we pass the id, and not the browse record.
This commit closes#12978
Without this commit, there was no warning displayed when clicking
on a button that would make the user lose all he entered in the
widget, which is insonsistent with other odoo widgets.
opw-684276
The report "Payslip" was displaying both the employee's job, the second time
being in the "Identification No" box.
Remove the second job and replace by the field 'Identification No' which makes
more sense.
Closes#12937
The only supported prefixes are the following:
- /partners/ when website_partner and/or website_crm_partner_assign are installed
- /customers/ when website_customer is installed
The error message has an hardcoded precision of 2 digits, which is not
enough of the product precision is higher than 2. Since this error
message is often used, we should avoid its modification to prevent
breaking the translations.
opw-683639
Fixes#12629
When the General Ledger is printed, the initial balance is zero if the
filtering is done by period.
It appears that in this case, the method `_query_get` selects all the
periods before the selected period range thanks to:
`build_ctx_periods(cr, uid, first_period, context['period_from'])`
On the other hand, `_query_get` builds the query as:
`date_start <= %(date_start)s AND id NOT IN %(period_ids)s`
That doesn't make sense since we first choose the periods before the
selected period range, then we exclude them. What the method
`_query_get` is doing seems wrong, but since this method is used in many
reports, it is safer to only fix the GL report directly.
Another solution could be
https://gist.github.com/nim-odoo/453176d9ae820615e69f9a809a3780cc
opw-681601
Before this patch, add_filter was called 2 times.
Once when we select a partner in the drop down, we trigger a onchange value
to change from false to the partner id.
Once to reset to false the value after the first add_filter()
This commit closes#9758
When the get_one_event_synchro crash, the status variable is not initialize.
So the return status, content, ... raise an error:
"local variable 'status' referenced before assignment"
This commit closes the issue #11513
Odoo Translation Bot
Christophe Simonis
Nicolas Martinelli
qdp-odoo
Pedro M. Baeza
Denis Ledoux
Raphael Collet
Jeremy Kersten
boogerlad
Luc De Meyer
Goffin Simon
Alexis de Lattre
chafique-delli
Damien Bouvy
javierjcf
Nicolas Mac Rouillon
Jairo Llopis
Alexis de Lattre
Jairo Llopis
Hans Henrik Gabelgaard
Jordan Vrtanoski
Martin Trigaux
Stefan Rijnhart
Pere Albujer
Julien Laloux
Moises Lopez - https://www.vauxoo.com/
Cristian Moncho
sergiov
baimo
Josse Colpaert
Paul Catinean
Antonio Espinosa
Olivier Dony
Martin Geubelle
Nicolas Lempereur
David Beal
Adrien Peiffer (ACSONE)
Alexandre Fayolle
Manuel Vázquez Acosta
Cesar Lage
Ravi Gohil
Christophe
Ondřej Kuzník
Gourav Chawla
aetna-softwares