It's unclear whether that's a recent change or a long-standing issue,
however currently if geocode is called with an empty address string it
will reply with a 400 Bad Request, which gets raised as an exception and
forwarded to the user. That is not a great experience.
Shortcut the entire thing and just return None (= geolocation failed /
no geolocation) on trying to geolocate an empty address.
OPW-746686
Let's create in google calendar a reccurent event with all day
set and a end date.
When synchronising google calendar with Odoo(by clicking on button
"Sync with Google"). It raised on error because the start date had
a time zone but not the end date(the UNTIL in the rrule).
Fine tuning of 20ed57f
opw:746549
stock_landed_costs: on nightly, the localization installed may not have stock properties accounts defined. If it's not, we create them on the fly with a random account
sale, sale_expense: fix broken tests due to mismatch currency:
On 10.0-nightly, the currency of the company is not the same that the product.list0
that leads to assertion errors.
The karma link is an hardcoded page from odoo.com. The information might
therefore not be correct depending on the configuration of the user.
We change to redirect to the FAQ, which also contains Karma information.
opw-746383
When the field use_create_lots is set to False in a picking type, it is not possible
to create lot for a pack operation linked to this picking type.
opw:744862
Add a constrains on user_id field to avoid to recompute manually the team_id.
Eg: action_foward didn't call the onchange manually, so the saleteam not updated.
If `d.message` is an empty string, `!!d.message` is false and the
crashmanager will try to display `d.error.data.message`… which does
not exist as it's a warning with an empty message not an upstream error.
That causes the crashmanager itself to crash, and even the warning
name/title to be lost.
Commits 9365482df0 and 8fc81b871d attempted to prevent the creation
of two moves with the same name during reconciliation. It works in most
cases, but it is still possible to reconcile the same statement line
with more than one line.
We add an extra check to make sure duplicate never happen.
opw-742018
This simple return allows submodules to be able to know when a dialog is shown and modify something in it.
Note from GED: I am aware that this is a IMP in a stable version, and I really don't like that... But it looks like it really helps many people, as shown by the PR, and the risk induced by this commit is definitely extremely low, so I will make an exception.
(PR: #15579)
When updating a carrier that is not "fixed" or "base_on_rule", this
method was creating unnecessary delivery.price.rule at each write.
This patch fixes this issue.
Closes PR #17443
In the journal items,
when performing a search
"Journal" "Doesn't contain" "Something"
Both its name AND its code must not contain "Something".
Therefore, with negative operator, the domain must
not be built with a OR connector but with an AND.
Same thing goes for "is equal" and "is not equal".
opw-726029
Attempting to read the field `website_price` directly
with the XMLRPC API failed because, in such a case,
the request is unbound, and attempting to read
anything from it (`request.session` whatever)
resulted to the raise of an exception.
e.g.
This prevented to perform a `search_read`
with all fields on the `product.product` model
Closes#14939
opw-745733
Let's create in google calendar a reccurent event with all day
set and a end date.
When synchronising google calendar with Odoo(by clicking on button
"Sync with Google"). It raised on error because the start date had
a time zone but not the end date(the UNTIL in the rrule).
Fine tuning of 20ed57f874
opw:746549
As a consequence of rev. 76cd8d2558,
imported modules were unable to access their resource files during
import.
Rather than further modifying the file_open API to whitelist paths
(the whole thing needs a redesign in master), we temporarily
whitelist the temporary directory by including it in the global
addons_paths, making sure to undo it afterwards.
This gives all lower level function access the resource files via
file_open, without having to pass around whitelisted paths
through many different calls.
- Use the demo resource calendar (40h/week)
- Create a project forecast for the Administrator
- Set the 'Start date' and 'End date' to 2017-07-07
- Plan 8 hours
The % of time should be 100 %, but it's not always the case.
The core of the issue comes from `get_working_hours`.
Case 1:
Call with start_dt = end_dt = 2017-07-07 00:00:00
`get_working_hours_of_date` is called twice with the following start/end
dt:
- 2017-06-07 00:00:00, 2017-06-07 00:00:00 => 0 hours
- 2017-06-08 00:00:00, 2017-06-08 23:59:59.999999 => 8 hours
This is obviously not correct, we don't care about what happens on
2017-06-08. The number of hours is correct in total, but it comes from
the wrong day.
Case 2:
Call with start_dt = 2017-07-07 00:00:00 and end_dt = 2017-07-07 23:59:59
`get_working_hours_of_date` is called twice with the following start/end
dt:
- 2017-06-07 00:00:00, 2017-06-07 23:59:59.999999 => 8 hours
- 2017-06-08 00:00:00, 2017-06-08 23:59:59.999999 => 8 hours
This is obviously not correct either...
We change how the `until` parameter is computed. This way, the correct
call is the second call (Case 2), and `get_working_hours_of_date` is
calld once with the following start/end dt:
- 2017-06-07 00:00:00, 2017-06-07 23:59:59.999999 => 8 hours
opw-745253
There were two main problems with the datepicker since the lib was
updated:
- it appeared broken in the search view "Filters" menu
- it did not overflow the parent which scrolls
Indeed, before the update, the datepicker was placed in the <body/>.
Now this is a lib option. Unfortunately, the option is broken (I don't
know why they broke it since it worked before the lib update...). As the
lib does not expose its internal functions, the only found workaround was
to patch the lib code itself.
opw-745311
opw-745625
Let's consider P1, P2 and P3 with a cost=1$, three stockable products where
P1 and P2 are in the same product category PC1 with a Stock valuation
account = SVA1 and P3 is in the product category PC2 with a Stock valuation
accout = SVA2. PC1 and PC2 are set with costing method in real price and
Inventory valuation = perpetual(automated).
Steps to reproduce this issue:
-Create a BOM where P3 is composed by 1 P1 and 1 P2
-Create a PO for P1 and P2 with a cost of 5$ for each one
-Create a MO to produce 1 P3
-Check availability
-Insert manually the consumed product(1 P1 and 1 P2)
-The button "Post Inventory" appeared, clicked on it
-Check the general ledger, two moves with debit=5$ has been created
for P1 and P2 in PC1(it's ok)
-Produce the MO and click on "Post Inventory" again
-Check the general ledger, two moves have been created, one with a credit of 2$
on PC1 and one of debit of 2$ on PC2(it was wrong)
The expected moves for the last step is:
a credit of 10$ on PC1 and a debit of 10$ on PC2 because the purchase price must be
considered as P1 and P2 are in real price.
NB: Everything is ok if the button "Post Inventory" is clicked after the production.
opw:741748
When validating a statement with old posted moves, the lock date
was checked by function, _check_lock_date and then it was impossible
to validate the statement even if all the moves were already posted.
If only Inventory is installed,
only the admin could create new product attributes
for products variants. Other managers couldn't.
This revision adds the ACL according to what is done in other modules,
such as in `sale`.
Mostlikely, we should create a product manager group, for which
this rights are given, and make the other groups (sales manager, inventory manager)
inherit from this one.
opw-745735
Let's create in google calendar a reccurent event with all day
set and a end date.
When synchronising google calendar with Odoo(by clicking on button
"Sync with Google"). It raised on error because the start date had
a time zone but not the end date(the UNTIL in the rrule).
opw:745665
For now, these tests do not work with another CoA than the generic one.
Depending on your testing infrastructure, they may or may not pass.
We skip then invalid CoA's and plan to make them work in master.
In case of a MemoryError, there is no error message, the user gets a
"Database restore error: "
without any details.
Instead fallback to the repr.
This way, a wrong password is
"Database restore error: Access denied"
and a memoryerror
"Database restore error: MemoryError()"
Closes#17393
On a pricelist, if multiple rules were set with the same
set of rules condition, the choice of which rule/item
is used was random, according to the postgres database
state.
Adding the `id` in the order force to always use the same
rule/item (the first that was created).
opw-744865
- Create an excluded tax of 20 %
- Create a customer invoice of 1000
- Create a payment of 900
- Make the matching between the invoice and the payment:
Write-off of 83.33, with the 20 % tax
Error: 'Cannot create unbalanced journal entry'
After commit 89cbef8540, the tax are by default not created
automatically anymore. We should make sure to pass the context key
`apply_taxes`.
opw-744266
When disabling the customer portal
in the general settings
(or uninstalling the `portal_sale` module directly),
the model `sale.order` no longer has a method
`get_signup_url`, and it therefore leads
to the fail of the email template rendering which is
still referencing this method.
Besides, the `access_url` is actually used only if
`is_online` is True,
(see the `% if is_online:` few lines later)
and in this case `get_signup_url`
was not used at all.
Therefore, we can assume `None` is a good alternative,
as the resul of `get_signup_url` was actually no longer
used.
opw-710481
If you have two invoices with a same product,
- one having 1 unit of a product,
- the other -1 unit of a product,
The sum of these quantities will be 0, and it will lead
to a division by zero in the former sql request.
The nullif should be applied on the sum, not on the line quantity.
opw-745073
This try except block was added in another era, where the piece of code
in the block was far less ambitious (and not for good reason since
adding a try except block because of a malformed mail template seems
overkill).
Even worse, this block actually prevented errors from bubbling, which
could have adverse effects.
Example: a long transaction confirmation (several seconds since it
implies S2S communication, invoice creating/validation, etc.) is
rollbacked because a mail message is recorded on the quote during
the processing time. The quote confirmation then crashes because of a
concurrent update error in postgres. This try except block does not
re-raise the error, which means that instead of retrying the operation
like the ORM would normally do, we have an incomplete traceback in the
system (since the error message crashes itself) and the transaction is
not validated (as far fetched as it may seem, this is in fact how this
bug was discovered).
This try-except block offers no gain in error logging (on the contrary,
since we have lost the initial error-causing statement) and prevent the
orm from correctly managing errors.
This commit removes it and let the orm handle the errors like a grown up
man; either crash for real (because it should crash to know if there's a
problem) or retry the transaction if it's a serialization issue.
opw-744629
Odoo Translation Bot