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
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
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
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
The attribute filters based on all products matching current domain was limited
to the first page of result only.
If all the products of the current page had no variant, no filter was displayed.
Closes#17361
When the user zooms with the browser, the bottom left pads are
misaligned for some zoom levels.
By slightly reducing the width of the action pad, this can be solved for
all acceptable zoom levels.
opw-745074
Use the field `time_cycle` for cost computation, which takes into
account the routing configuration (fixed time of computed based on
previous operations).
- Create a work center with a capacity of 1, an efficiency factor of
100% and a cost per hour of 40$
- Create a routing with two operations: one with a fixed duration of
30:00 minutes (OP1) and another with a duration computed on real time
but with a default of 30:00 minutes (OP2)
- Create a component with UOM "m" and a cost of 10$
- Create a finished product with an associated BoM
- The BoM has a first line with 0.8m of component in the OP1 and a
second line with 0.4m of component in the OP2
- Activate the Compute from BoM option on the finished product
- The proposed cost is 32$
Expected cost: 52$
(30 minutes @40$/hour + 30 minutes @40$/hour + 1,2m @10$/m)
We divide the WC cost by the number of operations, which does not make
sense.
opw-741032
An archived forum could still be posted in, something better should be
done in the next version (eg. website published present on a lot of
record type) but as of 10.0 just this improvement is done.
opw-745510
closes#17365
Fixed some issues with parralax image updates:
- Background updated without clicking
- Default wallpaper not coming back
- Background disappearring sometimes
In carousel snippet, the target element for background snippet option is
being changed manually. So for the new target, we have to rebind the
associated events that were bound in `start` function of the snippet
option. For that, some code is extracted from the `start` function and
is used to rebind necessary events for new targets.
In particular, this was preventing the carousel slides' backgrounds to
be automatically removed when a background-color was selected.
The context is not in the kwargs when the integrity error is raised from
a rpc request. So the user lang was lost and the sql error message was not
translated.
The part treating the callable message in sql error is depracated.
opw:743259
Portal users do not have access on invoices or invoice lines. However when
viewing an online quotation in website_portal_sale some computation is
performed based on invoices and invoice lines. We therefore iterate on
invoice and invoice lines as superuser as we do not want to grant any
additional access on those models for portal users.
Error thrown by google request is an urllib2.HTTPError that can be read
and loaded in JSON. However in some cases the result of the read may
be void or not JSON-ready. This was causing a crash in the error
management and hid the actual issue.
This commit tries to read and JSON-load the error but fall back on
simply displaying the raw error in case of issue when handling it.
Closes#17308 .
We need to ensure the account move lines we search for in case of partial reconciliation are within the period boundaries
Before this commit, when a partial reconciliation has been made long after others, the date used would have been this former move's
because of the MAX() function introduced by commit 3128e84243
Hence for one period, if that date were to be outside the period boundaries, the entire reconciliation would have been discarded, leaving the period due amount to 0, but a non-null total
This commit still uses the MAX() function, but specifies the aml date must be within the period boundaries
OPW 740793
OPW 725890
Closes#17098
Goffin Simon