This patch is a workaround waiting for the real patch in upgrade field widget.
Export source to match recent changes in account module
Closes#22984Fixes#20030
A big problem with the o2m edition happens when the user has a full page
(so, in general, 40 records) and click on add.
If the o2m is in editable="bottom" mode (which is actually a really
common usecase), then the next record will be added at the end.
However, since we have a limit of 40, it will immediately go to the next
page.
The effect is even weirder when there is a required field in the tree
view. In that case, the new record appears correctly, the user can edit
it, then, as soon as the required fields are set, it will immediately
disappear from the current screen.
In this commit, we have a really simple solution: we simply increase the
limit in this case. An interesting thing is that it is actually temporary:
when the user goes to the next page, the limit is back to its original
value (due to the pager click: it resets the value to what the pager knows).
Issue: when the inverse method writes on a dependency of the first record, it
invalidates the cache of the field for the other records... Solution: simply
evaluate the inverse method one record at a time.
The due date is printed on the invoice given to the customer and then
it is quite "official". That's why it shouldn't be correct to change it
when it's validated.
opw:1823175
When editing a view on the frontend with a dynamic chatter (chatter
added dynamically to the view), if that part was edited, that
dynamically rendered part would be saved as is. Thus we would get a
duplicated chatter (with the first one statically the rendering at the
edit time).
opw-1813792
closes#23593
The 'toggle_button' widget is one of special field widgets that
can trigger changes in readonly mode (in this case, toggle the
boolean value when clicked). It was working fine in form views in
'readonly' mode, as in this case, the new value is saved directly,
and the form view is re-rendered (a new widget is created with the
new value).
However, in 'edit' mode, the value isn't saved directly (the user
has to click on 'Save' to save the changes), the widget is reset
with its new value, and the reset wasn't correctly handled in this
particular widget.
Fixes#23400
Steps to reproduce the issue: on an MD sized screen (i.e. such that
the chatter is below form views), go to a sale order in edit mode,
scroll down and click on 'Add an item', a modal opens, and the form
view behind scrolls back to the top, whereas it should keep its
scroll position.
This is because the ActionManager listens to event 'DOM UPDATED',
and when it occurs, it restores the current action's scroll
position (the main purpose is to restore the scroll position of a
previously visited action to which we return using the breadcrumbs).
When a dialog opens, this event is also triggered, but in this case
we should not restore the scroll position of the action in the
background.
Fixes#23491
Before this commit:
1. The date would be displayed as UTC regardless of the user timezone.
2. The date would be sent to the backend in the browser timezone
Now we correctly take the user timezone into consideration when handling date.
Step to reproduce:
- Install a second language where time format is: %H.%M.%S or %H,%M,%S
(eg: Finnish, Bulgarian, Albanian )
- Set it as website default's language
- Open page properties dialog on any page
- The date looks correctly displayed but it is in fact the UTC hour and not
the user timezone date. (eg: 2 hours missing in Albanian case, it would
show '2018-Pri-05 02.11.02.' instead of '2018-Pri-05 04.11.02.')
- If you save, it will crash since it will send the wrong date format to the
backend that is expecting 'YYYY-MM-DD HH:MM:SS' format.
Closes#23500, closes#23566
Commit 4ecbacaf59 changed the XMLID of the `contactus_thanks` page,
but didn't adapted the .pot file. Therefore, the translations were not
loaded anymore.
opw-1813360
When the `create` or `write` method receives an empty string for a date
or a datetime field, PostgreSQL will fail since this is not an accepted
value for this field type.
We fallback on `None` for falsy values.
opw-1819336
@KangOl : watch out when forward-porting, the signature of
`convert_to_column` has changed in saas-14.
- Go to 'Contact Us' page
- Edit, then try to change company data
- A dialog window asks if the user wants to edit the company data
- Confirm
It redirects to an unexisting page.
opw-1825662
Before this commit, when clicking on a event of a pinned calendar view
in the Dashboard app, nothing occurs.
The cursor turns into pointer type when hovering on an event, suggesting
that clicking on it should do something. Kanban and list views redirect
the user to the document's form on click, so a similar behaviour is
expected with calendar view.
This is indeed the case in v11, but not in v10. The reason that it works
in v11 for calendar is that when we click on a record of a pinned views
in dashboard, it performs a do_action to open the form view. In v10, however,
it performs a do_switch_view to the form view. Since there's only one view mode
when we pin something in dashboard, the processing of the click fails silently.
Kanban and list were working because the dashboard app overrides their
handlers functions when loading the views, which wasn't the case with calendar.
This commit solves the issue by also overriding the handler function
of calendar view, so that it performs a do_action to open a form instead
of performing a do_switch_view to the form view.
(Note: pivot and grid views work, because they use do_action)
opw-1817725
Properly override `_track_template` similarly to what is done for
`project.task`, so the method can accept a recordset.
Co-authored by: Nicolas Martinelli <nim@odoo.com>
Closes#23466
opw-1823244
Our positionning of the scan line (ligne de codage) was possibly wrong
depending on wkhtmltopdf.
In eg. chromium the font is configurable exactly but in wkhtmltopdf it
seems there is bigger limitation on giving eg. a decimal pixel number.
But this was necessary to have the same character positionning than
expected in BVR, and this line is read by scanner and must match.
This change:
- have an absolute positionning for each character in the scan line
- add two parameters "ISR scan line horizontal/vertical offset" that
will move the scan line to the choosen distance.
- changes some other CSS value to match better the ISR documents on
accounting on differences between wkhtmltopdf 0.1.2.1 and 0.1.4.1
- remove currency which should be on the BVR background.
opw-1813776
closes#23518
Complements rev. 9b1009cd5a to fix the
handling of validation transactions for 3DS-enabled cards.
This handles a few issues:
- make sure to trigger the refund for validation transactions even if
the first feedback we get is the S2S feedback
- feedback URL called by the users' browser should not reset the payment
transaction to 'done' when the refund process has been initiated
- status 81 for "refund pending" should not end up with a transaction in
error. It may be that Ingenico will send a feedback transaction later
or not at all, but the refund is likely to succeed at that point.
Without this commit, validation transactions would never be refunded for
3DS cards.
Remaining issue: the return_url does not seem to be set for those
validation transactions, so the user ends up on the homepage after
completing the 3DS step.
* In account.journal model, the domain of bank_account_id field was incorrectly comparing the partner_id with a res.company object
* When modifying the company of a bank journal, the company of the related res.partner.bank was changed without checking if it had a company and also its partner (account holder) was not changed.
Was PR #23480. Courtesy of Miquel Raich (Eficent)
Before that, partial payments on open invoices were ignored by the query, due to the fact we used checked "reconciled=false" instead of "full_reconcile_id is not null".
Before that, partial payments of invoices were not shown into the partner ledger unless the option to show reconciled entries was activated. This was due to the fact we checked full reconciliation with the field "reconciled" instead of the full_reconcile_id, so the query did not return the partial payments (which have reconciled=True, but don't have any full_reconcile_id unless the invoice is fully paid).
Revision ec96c0b3c2
attempt to display the VAT label according to the country
vat label.
This a very commendable effort, except that the
`vat_label` was not available under the variable
`company.country_id.vat_label`
Actually even `company.country_id` was undefined.
This revision does what it must be done in order
to read the countries `vat_label` and to make
it available through a variable for the bill receipt.
opw-1817333
- Set 'Round Globally'
- Create an excluded tax of 10 %
- Create an invoice for a product costing 34.55, and apply the tax.
The tax on the invoice is 3.46, while the tax on the tax line is 3.45.
When rounded in `compute_all`, the tax amount is 3.455, which is the
value expected. However, the `create` method won't round this value
before storing, leading to the inconsistency.
We make sure the currency is sent at saving, so the method
`convert_to_column` receives the appropriate values for rounding.
opw-1819902
Before this commit, the twitter share (intents) would encode the URL twice.
The URL on the tweet would then be broken.
Eg: https%3A%2F%http://2Fwww.odoo.com%2Fforum...
Use case:
Have a user with access rights "See Own leads"
In the CRM settings check the "use leads" boolean
Before this commit:
This user couldn't create a lead directly nor qualify it as an opportunity
AND
the default sales team on the lead displayed as 'Unknown'
After this commit:
This user can read the sales team, even though he is not a member of them
He can create leads on the default sales team
And qualify them as opportunities
OPW 1816309
ref #22360
Make an invoice
Make a payment
Unreconcile them
Before this commit:
The invoice and the payment weren't display in the aged partner balance
After this commit:
Both payment and invoice *can* be included in the balance
OPW 1819359
Changing it is not needed and generated missmatch against existing
entries (created by l10n_generic_coa demo data, thus depending on module
install order).
This could (should?) be considered a refactoring, but this is actually
trying to restore lost functionality. In v10, the custom form widgets
were created with access to the node element that define them. We lost
that in v11, with the new views.
However, it is actually very useful for generic widgets. Since this is
not really a risky fix, I think that it can be done in 11.0.
Note: this feature was already reintroduced in master in commit
https://github.com/odoo/odoo/commit/b7aa439826df6b3e442b3f60bb593ff28efc8679
As of v11, project tasks and project issues have been merged.
Issues used to be ordered by:
priority desc, create_date desc
whereas Tasks had the following historical ordering:
priority desc, sequence, date_start, name, id
(where `date_start` corresponds to the creation date of the task, or the
time where task work began)
After the merge, the Task order was kept, but it became difficult to
understand for users, especially for converted issues.
This commit modifies the default order to a more obvious common order:
priority desc, sequence, id desc
With the following goals in mind:
- the ordering does not change without obvious actions of the user
(starring a record moves it at the top, manually reordering records
reorders them within the same "stars category), and creating new
records adds them at the top, where they are visible
- the ordering is easy to grasp, based on stars and chronological
order, while still allowing manual reordering when really necessary
(by default all records will have the default sequence of 10)
- sorting by "id desc" is similar to the previous "create_date desc"
but it can be sorted more efficiently by the database
One could argue about sorting on chronological or reverse chronological
order. Like blogs and timelines, everyone has their preferences.
The latter option was selected because our UI for quickly adding records
is at the top of the kanban view, so it is more natural to see new
records at the top, instead of having them disappear at the bottom
immediately.
Hopefully this will not disrupt user workflows too much, and will remain
intuitive enough.
The validation transactions introduced in
7d428c871b were not working properly for
Ogone, due to several problems:
- The refund requests when being sent via the orderdirect.asp API, which
does not support refunding previous transactions, according to the
Ingenico helpdesk. It only support creating independent refund
transactions, which is something that requires special pre-approval
from the payment acquirer, and generally not permitted.
In order to cancel/refund a previous transaction, the direct
maintenance API must be used instead[1].
- Maintenance requests to refund a previous transaction fully should use
the RFS code, as explained in the API documentation [1], and should
always mention the PAYID of the refunded transaction.
- Such maintenance requests must always be SHA-signed, as usual.
- The various transaction status codes for refunded transactions need to
be taken into account as well (typically those beginning with 8)
This commit fixes these various problems.
[1]
https://payment-services.ingenico.com/int/en/ogone/support/guides/integration%20guides/directlink
(5.2 Direct Maintenance)
As of today, Ingenico platform 4.125 has non-uniform handling of the
PARAMPLUS parameters that can be passed as part of transaction metadata.
This parameter is documented as being parsed[1] as a series of
parameter-value pairs, to be passed as extra parameters to the feedback
transaction. Based on this, it seems that the PARAMPLUS value should not
be urlencoded globally, but each field value should be urlencoded, as
the Ingenico side will have to be able to parse and re-emit these
individual parameters.
In one case we were missing this urlencoding step, so this commit fixes
it.
Without this, the querydirect.asp API would return invalid XML data when
we retrieve the status of a transaction that used a PARAMPLUS value with
an '=' sign!
For example with PARAMPLUS passed as
return_url=/payment/confirm?tx_id=123
the value returned by querydirect.asp would contain the following:
(note the invalid extra quote character in the `return_url` param)
```
<?xml version="1.0"?>
<ncresponse
(...)
ED="1234"
return_url="/payment/confirm?tx_id="123"
SCORING=""
SCO_CATEGORY="G">
</ncresponse>
```
Url-encoding the value of the return_url in PARAMPLUS fixes this
nonsensical result.
However, the Ingenico API then fails to decode the parameter value when
passing it to the feedback URL, such as the ACCEPTURL we depend on.
As a workaround, since we only pass a single parameter inside
PARAMPLUS, we'll url-unquote it afterwards.
[1]
https://payment-services.ingenico.com/int/en/ogone/support/guides/integration%20guides/e-commerce#feedbackparameters_variablefeedbackparameters
Before this commit:
When editing a page URL through page properties it would redirect to that new
url afterward. If the url was not starting with '/' and had multiple level
before and after edition (eg: page/action to page/realaction) it would then
redirect to a wrong relative URL.
Now, we ensure that we redirect to the correct URL: the one slugified and
cleaned in the backend.
Step to reproduce:
- Create a page '/page/action'
- Go to that page and open Page Properties
- Edit the URL to 'page/someaction'
- You will be redirected to the incorrect relative URL /page/page/someaction
When the type of a product is changed by a user of company A, if this
product has been sold previously by company B, the user receives an
access error.
opw:1824548
Configurations uses an onchange to populate the fields visible to the
user. However, the related fields are by default called sudo, when it is
an onchange, there may be a missmatch in the cache, the cache used being
empty, there is no value to return (cache fix is not currently possible).
Before this fix we must use 'related_sudo=False' to use the good cache but
it's an inconsistent fix because in some case we must use sudo to avoid
access error.
opw-1823363
When looking for the move line associated to a quant, make sur to return
the move lines that took from the package or that put something in the
package.
opw-1824578
- Set the product price decimals to 5
- Create a product costing 0.32
- Create a pricelist with 20 % discount when quantity is > 100
- Set a default fiscal position on the POS
- Lauch a POS session
- Add 500 units of the product
The unit price is rounded to 0.26, while it should be 0.256.
This is due to the call to `compute_all`, which will round to the
currency precision.
opw-1816997
The payment lines shown in the payment widget on invoices, should only list reconciliation made towards the lines sharing the same account as the invoice/bill. Previously, if a tax or an invoice line was using another account set reconciliable, any payment made against this account would be shown in the payment widget, which is wrong.
OPW: 1805968
Grzegorz Krukar