The field state was replaced by ‘active’ in project.project (see commit 9b69184).
However, someone forgot to update the arch for the default list view which
was not longer possible to open.
This is triggered by the interaction of the `-webkit-overflow-scrolling` [1]
rule that is set on the top of the modal (div.modal) and the fact that inputs
elements are displayed over the table with an absolute positioning (that's
how the editable lists work).
Indeed, the `-webkit-overflow-scrolling` rule creates a new stacking context [2]
and is inherited by all the children of the modal (and so on), resulting in this
situation:
.modal
/ \
... (new S.T.) ... (new S.T.)
/ \
... (new S.T.) ... (new S.T.)
/
.o_list_editable (new S.T.)
/ \
.o_form_view (new S.T.) .table-responsive (new S.T.)
/ | \ \
input input input table (new S.T.)
This explain why the input are not visible: actually, they are displayed
behind the table. In this case the document order is used to know which
div should be in front of another div[3], that's what rev odoo/enterprise@304b790004 [4]
tried to change. However, this was not enough for iOS 9.3 / iphone 6
because, for some unknown reason (but probably due to the fixed position
of the modal that seems kind of broken on safari mobile), the inputs where
still displayed under. Note that the fix was ok for ios 9.3 / ipad air 2.
The fact that `-webkit-overflow-scrolling` creates a new stacking context
at every node seems odd, unfortunately removing the rule result in a non
scrolling div at all.
The fix is to explicitely tell the input to appear over the .table-responsive.
This is done by sharing the same stacking context under the common parent
between the form and the list view: .o_list_editable. For that, we prevent
the creation of a new stacking context under .o_form_view by reseting the
`-webkit-overflow-scrolling` to "auto" and we set a dummy z-index to the
inputs element. As they are the only one to have a z-index in this dom
range, they will always appear on top of the table.
With this solution, the `-webkit-overflow-scrolling` is still inherited
correctly and the div is still scrollbale.
This fix unveils another issue with the editable list: if the screen is
too small resulting in an horizontal scrollbar, the table in itself is
scrollable but the inputs aren't.
opw 683169
cherry-pick of odoo/enterprise@35f285e50a
[1] this rule allow a smooth scrolling of the content of a div on iOS
https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-overflow-scrolling
[2] https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/The_stacking_context
[3] https://www.w3.org/TR/CSS2/zindex.html
[4] This commit has been reverted with odoo/enterpise@287cff02c7
and never forward-ported to saas-10.
Fix "Remove cart line button isn't a proper link"
Fix "col-md for title (Billing Address, Shipping Address) where 'The underline of the title stops too early'
Fix "First load from adress, display zip/city in right order to avoid flickering if zip/city instead of city/zip
Fix "Select the billing address as the shipping after edit the billing address from the shipping list"
Fix "Disable the selection of address in checkout while in edit mode"
Fix "Fix validation of the extra checkout step: 'extract_data got an exepected keyword argument'
Show to the end user that he should be logged in to use action where karma
is required.
Before this commit, a user not logged in see that x karma is required to
perfom the action.
After this commit, a user not logged in who click on an action which require
karma will get a message "Sorry you must be logged in to perform this action"
This commit closes#12731
Searching on the name of an account can lead to a traceback ("This
domain is syntactically not correct"). This is for example the case in
Accounting -> Configuration -> Taxes -> Custom filter on "Tax account
doesn't contain 'xxx'".
The reason is that the negation of the domain is not correct.
opw-684525
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 choosing to refund an invoice with refund method="create refund, reconcile and create a new draft invoice"
, the fiscal position of the refund invoice must be kept in the new draft invoice.
opw:683311
This is the proper fix for 3180aec56a
and is the continuation of f7e4241a91.
A sum without groupby will return NULL so we forced it back to 0,00.
Then, it can happen that you have no move before the start date, so you
don't have any opening "OUV" row.
opw-682365
When using the -i command line option without the --without-demo=all command
line option, demo data was installed even if the configuration file has
a line without_demo = all
This change is safe as just above, opt.without_demo is copied into
self.options['without_demo'] so we are sure to consider the 2 options.
Closes#12730Fixes#9293
If multiple transactions start knowing that they should generate the
bundle, each one will run lessc and create a ir.attachment record
referencing the path on the filestore. While the file is not duplicated
on the filestore (as it is stored according to its hash), the final
result of `t-call-assets` will source multiple time the same file.
This patch fixes this issue by adapting get_attachment to group its
results by file name and only select the one with the max id (latest
generated).
We also remove the `inc` argument as it is not used.
Commit 4326d864 removes the inverse function of the `date_planned`. This
is necessary to avoid unexpected changes of the scheduled dates.
However, this removes the ability to set the scheduled dates of all
lines at once.
This commit introduces back the functionality thanks to a new button.
This way, the functionality remains without unexpected behavior.
when we unreconcile an entry, amount_residual is not recompute due to missing dependencies. Resulting in problem when trying to reconcile the move later on as amount_residual is zero and aml is considered already reconciled
The previous fix didn't take into account the fact that some parts
of the file can truly be empty. Because of this, you end up with
'0,00' in some date fields.
This commit fixes a bug introduced by the forward port 1fca5e01cb.
In saas-11, the commit f970906c9e introduced the 'assets' value
for the debug mode, to active the assets splitting. To do that, the
commit had to stop the conversion to a boolean of the debug value
(initially introduced by commit 522dec2fcd).
The problem is that the forward port mentionned above did not resolve
correctly the conflict for the commit 3455daf948, reintroducing the
boolean conversion.
The menu `account.menu_finance` is named "Invoicing" in account and renamed
"Accounting" in account_accountant.
The renaming introduce 2 translations that are both in account.pot (as the
translation of an object is based on the module that created it, deduced from
the external id, here account).
When installing account module, two translations for the same item are loaded.
Remove one of the translation (keeping "Accounting" as it is probably what most
people using accounting will have) to avoid uncertainty from a duplicated
translation.
A correct fix would be to avoid renaming the module (will be done in master).
opw-683314
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
The aml.balance in the sql request is null, so the string encoding
fails with an error. This is a quick fix because the customer needs
this report for tomorrow, but a proper fix is required !
Allow to round the duration to a minimal unit.
Eg:
0.33 hour = 19.8 min = "19 minutes 48 seconds"
if option {'widget'='duration', 'unit'='hour', 'round'='minute'}
0.33 hour => 20 min = "20 minutes"
A misleading behavior occurs with the recomputation of scheduled date.
Here is the use case:
- Create a PO with 2 products
- For the product 1, set the scheduled date to today + 7 days
- For the product 2, set the scheduled date to today + 14 days
When saving, the scheduled date of product 2 is reset to today + 7 days.
This is of course unexpected, but moreover, a different behavior can
happen depending on how the scheduled dates are modified. In the
previous case (both products have now the same scheduled date), one can
observe 2 situations.
Case 1.
For the product 2, set the scheduled date to today + 14 days and save.
In this case, the scheduled date of product 2 is not reset.
Case 2.
- For the product 1, set the scheduled date to today + 8 days
- For the product 2, set the scheduled date to today + 14 days
In this case, the scheduled date of product 2 is reset to today + 8 days
when saving
The reason of a different behavior in the 2 situations is that the
scheduled date of the PO is changed in case 2 and not in case 1. Since
the scheduled date of the PO is changed, it triggers the inverse
function `_inverse_date_planned`.
When saving, it is not possible to know whether the scheduled date of
the PO was changed on purpose by the user or recomputed. There are 2
solutions to get a consistent behavior:
- Force the scheduled date of each line to be the same than the
scheduled date of the PO. However, this makes the scheduled date of
the line useless.
- Do not change the scheduled date of the lines when the schedued date
of the PO is changed. However, this removes the ability to reset
automatically the scheduled date of the all lines at once.
This is the second solution which is chosen with this commit.
opw-682934
opw-684063
Closes#12904
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
Josse Colpaert