Before this commit, changing the value of a many2one field on the
frontend was not possible anymore since 11.0 because the RPC 'order'
parameter was not properly formatted with the new conventions.
See task-1767802
Closes https://github.com/odoo/odoo/pull/23545
Before this commit:
* Activate debug mode.
* Go to general settings > Document Template.
* Change the Template selection to the empty value.
* Click on "Edit Header".
Result: Traceback.
This happens because we try to concatenate the value of the template
field to a string, and since it's empty (False) boolean and str can't be
implicitly concatenated, this of course raises an uncaught error.
After this commit:
* We check if a template has been selected before performing the
concatenation.
Closes#22736Fixes#22622
Before this commit:
* Install any module that creates a SQL view and another that extends
this view.
e.g.: sale and pos_sale for `report.all.channels.sales`.
* Uninstall the module that extended the SQL view.
e.g.: uninstall pos_sale.
* Try to access the view from the web client -> Traceback, table not
found.
This happens because when reloading the registry, postgres drops the sql
view and it must be re-initialized.
After this commit:
We solve this issue by calculating all missing tables/views during the
uninstallation process, and re-initializing all of them right before
reloading the registry.
Also remove sql-view hacks in the modules `sale` and `sale_margin`.
Fixes#23528, #23529, #23530
When activating the list view of product and description, if the
description was too big things were overflowing over their box and
became unreadable.
The issue is that the height limit on description was of 200px for
tablet device and there was no lower limit. Thus the limit of an product
line being 200px: the description + picture could break out of the box.
With this change, the description at lowest width devices is limited to
40px as is the case for the grid view (which is very similar on low size
devices).
opw-1819184
closes#23604
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).
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
- 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
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)
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...
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
Before this commit, images in kanban view of the Contact app were not displayed
on non-latin languages, such as Russian.
This was caused by the is_bin_size helper that wrongly assumes that a certain
string is not a binary size, although it is (e.g. 64.2 Кб).
This commit fixes the issue by including such strings as valid binary sizes.
Bug found and fixed by @true-datura
Test by @alexkuhn
closes#23526closes#22519
When a chatter is displayed and the document is accessed with a valid
access_token, the message related to the document are searched in sudo.
This bypass valid filtering we may down the line.
This change apply the filtering so note type messages are not displayed
for user who are not employees.
note: before 11.0 this logic was in 1b5c2ced. In future version it would
probably be better to have a method eg. _get_domain_based_on_user
that would be called before sudo and if not sudo.
opw-1819702
closes#23544
Before this rev., the field widget 'mail_activity' kept an internal
cache of fetched activities (like the 'mail_thread' and
'mail_followers'). However, for activities, this cache may cause
issues.
For instance, create a new lead in 'My pipeline', schedule a
'Meeting' activity on that lead (it opens the Calendar view so
that real meetings can be created), create a meeting 2 weeks from
now, go back to the lead form view: the activity still diplays that
the meeting is today (when the view is refreshed, the correct date
is displayed).
This rev. removes the internal cache for this field widget, as the
activities can easily be updated in business flows (unlike messages
or followers).
This rev. also fixes a bug in the BasicModel, where the res_ids of
a list datapoint was altered in place to return a list of x2many
commands instead of the list of ids when being stringified. This
caused a traceback when opening a lead with activities, as soon
as the internal cache had been removed.
Steps to reproduce the bug:
- Set your company in anglo-saxon
- Create a product P in a category which is in real price and perpetual
- Create a PO with P at 500$ and validate it
- Change the unit price of P in the PO line and set 100$
- Receive the product
Bug:
The two journal entries generated for the goods were created with the price unit
500$ instead of 100$.
Fix:
Now the right price is taken into account to generate the journal entries.
opw:1813946
Before this commit, model that create ir_ui_view via _inheritS was ignored in --dev xml
The arch_fs was not set. Because it was not ir.ui.view, and because xml_id was suffixed by _ir_ui_view.
Now we manage the case of inherits. So if model model.name inherits ir_ui_view
class MyClass(models.Model):
_name = 'model.name'
_inherits = {'ir.ui.view': 'view_id'}
view_id = fields.Many2one('ir.ui.view', string='View', required=True, ondelete="cascade")
...
<record name='model.name' xmlid='pok'>
<field name='arch' type='xml'>content</field>
</record>
will be read from xml in dev mode.
parsing the xml file for xml_id pok_ir_ui_view and pok.
The orm by default will add this suffix.
The 'dynamic' view created when we update the groups is a special case, which we don't want the arch_fs
for dev mode because the xml only contains by default and an empty container and btw the imd was wrong
since we had the res.group model a xml_id into the _inverse_arch.
The page create via a template (method new_page) will automatically remove the arch_fs since we don't
want to see the empty container if we are in dev_mode.
When the inventory adjustement has been validated, changing accounting_date has no
impact on the stock moves created by the inventory adjustement.
This behavior cannot be changed in stable version.
opw:1817813
When a pricelist was set on the public user that was different from that of the
website, the prices were displayed using the public user default currency,
but the currency symbol displayed was the website default currency.
The issue was that in the template, the currency was accessed as a computed,
related field of website while the price was obtained using a function call.
In the first case the field was obtained using sudo, and thus the call would not
get the public user pricelist.
opw-1817761
Darshan Kalola