When we discard an element, we want to make sure that the new state is
not corrupted by previous user operations. In our case, we possibly had
a limit and an offset values modified by the user.
This could lead to unpleasant situations, with incorrect data displayed
on the form view.
Note that this actually fixes a new bug introduced by commit
https://github.com/odoo/odoo/commit/e7fab234201e357da52c3576ad2e8fc9ceee9359
(this is the commit that introduces the tempLimitIncrement attribute)
The issue here is quite simple. If we are editing a multipage one2many
field, then we click on the pager, we need to properly unselect the
current row.
If we do not do that, then we can enter invalid data. For example,
assume that there is a readonly field. We click on add, it creates a
(virtual) record with no value for that field. When we click on the
pager, we select the next page, and bypass all validation.
When we are in the process of adding a record, we do not want to update
the pager count. The reason is that if the user is at the limit (so,
1-40/40, no pager visible), then click on add, there will be a pager
shown with 1-40/41. Now, imagine that the record currently being added
as a required field, and the user clicks on the pager. In that case, we
need to discard the newly added record (bringing the total back to 40),
then move to next page, which does not exist anymore.
So, to fix this issue, we simply consider that a record being added
does not count, from the point of view of the pager.
When making a payment with authorize.net by clicking on "Pay Now" in the shop, it was
possible to send several transactions for the same SO because the button "Pay Now"
was enabled before being redirected.
opw:1819588
- Create a product with 3 variants
- Put a picture on the template, then on all variants but the first one
(the one with computed for field `product_variant_id`)
- Check "Multi image" setting in website config
In the product page of the eCommerce, the carousel is not displayed.
This is because the template only checks if the first variant has an
image in order to display the carousel. It should check all variants.
opw-1823242
On the product_normal_form_view
to be consistent with the product_variant_easy_edit_view view.
product.attribute.value values should not be modified from the product view but
using the variant configuration from the product
Consistent with what was wanted at a4d88c9efdCloses#23298
Before this commit, linking was enable for pivot view of model sale.report.
User that click on a cell will be redirected on a default view list/form
with all fields.
Now linking is disabled.
If you want to open the sale order on click, you need to start with the
pivot view from model sale.order.
This commit closes#23445
Purpose of this commit is to explain with more details how to write commit
messages. Content of the Git section is also updated with last decisions
and conventions.
60c920d4a should solve duplication of chatter when editing the website.
But portal module doesn't depends on website, so eg. on a instance with
just helpdesk (and no website) we would not see the chatter on the
frontend.
This fix reverts 60c920d4a and adds another solution not depending on
website.
opw-1813792
closes#23614
Steps to reproduce the bug:
-Just purchase a simple product using Authorize.net
-Click on "Pay Now" to be redirected to Authorize.net gateway
Bug: The company field added during checkout page was not filled.
opw:1817597
On an editable line with a many2one
Click to create a record
Click on create a record in the many2one
It opens the form view of the object in a modal, which has a many2many list, which choices are domainized
Click 'add an item' on this list
It should open a modal with the filtered choices
Click on any of the existing record
Before this commit:
There was a traceback in JS
That was because the event bubbled up to a parent, when it shouldn't
After this commit:
The whole flow unfolds without errors
OPW 1823205
Before this rev., this attribute was ignored for groups containing
sub groups.
Task 1786309
Closes#23514
Co-authored-by: Mohammed Shekha <msh@openerp.com>
This rev. increases the wait interval of the redirect handler
called when a document is clicked in a mail thread (e.g. in the
'Inbox' in Discuss). This increases the protection against
double-clicks (preventing the document from being opened twice,
thus making twice the required RPCs, and from appearing twice in
the breadcrumbs).
A more robust solution (at the ActionManager level) will be
developed for saas-11.2 (where the ActionManager has been
refactored and is testable).
When the bottom left and right areas were taking to much space, the
right one overflowed the kanban card, because those two areas
weren't allowed to shrink. This might occur for example on the
sale.order view.
This rev. improves the layout of the inner kanban view for
operators in livechat channels, mainly by setting a max-width on
their avatar (with classname 'o_kanban_image').
The motivation of this commit comes from a feedback following an
internal migration.
On the website when selling a ticket, a percentage discount may be
applied on the ticket price.
This percentage is calculated as:
{event product price} - {event product price reduced} / {event product price}
So with a ticket price 20, a linked product priced 60 reduced to 30, we
would get a ticket price 10 on the website.
This commit hide the discounted price if the pricelist that is applied
was configured as "Discount included in the price".
opw-1807889
closes#23611
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).
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
ougc27