When the picking type doesn't have use_create_lots or
use_existing_lots the products should end up in one
stock.move.line. The user will then be able to validate the picking
without specifying serial/lot numbers.
sale_payment method to check or create a new transaction when paying
a sale order should be named _check_or_create_sale_tx and kept private
like account_payment one. Both versions exists. This commit fixes
the typo.
Commit 55549f1e61 changed the way bindings between action and
contextual menu entries are generated. However a typo was introduced
linking Invoice Orders to sale order lines instead of sale orders.
This commit improves the use of mail activities by allowing their
integration with the calendar. Activity types now have a category
field that can be used to trigger some specific behavior. First
specific behavior is to have activity types of meeting category.
Creating activities of this type trigger a jump to the calendar to
schedule the meeting. Meeting activities and calender events are
linked to be able to easily navigate through the document, its activities
and its meetings.
Configuration is done using a category on activity types instead of some
hardcoded "meeting" activity to avoid issues with master data and to be
able to choose which activity type should trigger this behavior.
Linking calendar.event to documents is a good idea to allow searching and
filtering meetings. It also allow to have a link to the document from a
meeting and ease navigation.
There are currently some specific links (opportunity_id for crm.lead and
applicant_id for hr.applicant) but this commit allows some generic
document linking through a res_model_id / res_id fields pair.
As unlinking calendar events leads to separate flows depending on the
event being recurrent some fields are recomputed in cache even if records
have already been deleted. This leads to issues when computing recurrence
and accessing some event data. Let us therefore avoid recomputing fields
when unlinking events.
* fix typo, widged is actually widget;
* support name coming from context for calendar event quick create;
Support of context could be made generic in quick create mechanism but
in the meantime this fix is considered as sufficient for the use case
we have.
When unbuilding an order with serial number, the quant with the right
serial number must be found in the system either it raises an UserError
explaining what's the problem.
PS: A problem was found when we tried to unbuild two times the same MO.
After the first unbuild, we deleted it and recreated the same one.
opw:748472
- Set the browser to language 'Spanish (Latin America)' ('es-419')
- As a public user, open a livechat session.
The session doesn't open.
The root cause is the creation of a mail channel which contains
translatable fields (e.g. name). This attempts to create translations
in the 'es_419' language. However, this locale doesn't exist in Odoo,
and it triggers the constraint 'lang_fkey_res_lang'.
In this specific case, there is no real reason to translate the channel
name. Therefore, we simply avoid it thanks to a context key.
opw-766489
- datepicker doesn't default to current date by default
- date string in the input is now selected when clicking the field
- adapted the existing tests to the new changes
When a x2m field is modified, the 'save' rpc doesn't send 'False' as second
argument of the special command that manipulate the set of records.
From now on, the virtual id of the record is sent to the server as second
argument. This commit fixes the tests making the assumption that 'False'
was sent.
Fields sent from the client are pretty much always *text*. This can be
problematic for image fields sent as base64 *text* as in Python 3 the
base64 routines only work between bytes.
Alter the core field-resizing function (image_get_resized_images) such
that it ensures text base64 sources are encoded back to bytes before
being forwarded to the main resizing routines (which I don't think
should deal with *that* issue).
Fixes#18985: error when trying to update a company's logo
There is some odd behavior especially inside a editable containing
newlines.
For example in the sale description on an ecommerce item, lines could
contain newline (it is editable from backend) but as an effect of other
use case, pressing enter could have a range of unwanted side effects:
- removing all the content,
- duplicating the editable (should never happen, if we have one field
"description_sale" we don't want to duplicate it, this has no sense)
In a product name which is in the same use case, there is no newline so
the problem is not apparent, and ENTER do nothing. This is the behavior
we should want in every instance.
If we still want a newline, we have to force it with SHIFT + ENTER key,
also this is regarding field that may or could be present in the backend
views, so it could also be edited in backend.
This change make ENTER ignored when we are editing a node directly child
of an node being edited.
A second part of the issue was that dom.removeBetween (used to remove
content inside a range) could remove the ancestor node that was an
editable. This is not wanted.
For example if we did CTRL + A inside a field with `<br />` then ENTER
or pasting something, the field would be removed and not just emptied
and could not be gotten back without editing the template manually.
This was sometimes mitigated because if a `<br />` was at the end of an
element, it would stay in this use case avoiding the issue.
note: not necessary after saas-16
fixes#17445
opw-751360
closes#19313
- Force vertical margin to 0 in case the class is added to elements
that comes with a default margin (eg. titles tags)
- Move title & subtitle rules at root level
Before this commit, the chatter was rendered as an empty <div/> without
any class while in creation mode. This <div/> was then placed inside
the .o_form_view_bg element by mistake, as it did not match the
'.oe_chatter' selector.
The goal of this review is to have a layout which is correct to
implement the enterprise side-chatter.
This also removes/fixes deprecated community rules and xml templates.
Some countries, such as Canada, are using letters in their zip code.
When we check if the zip code is within the accepted range, we should
make sure to normalize it by making it case insensitive.
opw-767866
Commit 6a366b216b introduces a subquery when fetching translations in
order to avoid fetching duplicates. On large a `ir.translation` table
(~500000 records), this can cause a major performance degradation when
the user is not using the English language.
A typical example is a `read_group` call such as:
```
self.env['stock.quant'].with_context(lang='fr_BE').read_group([
('location_id', 'child_of', self.env.ref('stock.stock_location_stock').id)],
['product_id', 'qty'], ['product_id'], limit=80)
```
When no `orderby` parameter is used, the `groupby` fields are
implicitly used for ordering. While this makes sense for direct calls
from the web client, this implicit order might be problematic for
programmatic calls (such as computed fields). Indeed, in case of
grouping by product, the subquery mentioned earlier is used to sort by
product name. This is costly, and in most of the cases useless.
The workaround is to explicitely order by `id`, to avoid the use of the
subquery. For the upcoming version, a cleaner fix should be made in
order to prevent duplicated translations, and get rid of the subquery.
opw-767532
In an embedded editable list view with the widget `handle`, resequencing a
record and try to edit it afterwards won't work. The selected record isn't the
correct one, as if the resequencing had no impact.
To make this work, the list datapoint needs to be ordered by the field with the
widget `handle` ; if it isn't, resequencing the records won't change the x2many
data order but the list view expects the same order.
In an editable list view with the widget `handle`, resequencing a record
and try to edit it afterwards won't work. The selected record isn't the
correct one, as if the resequencing had no impact.
A small refactoring has been done to fix this because the resequence logic
was placed in the ListController (but should logically be placed in the model).
Several views are using the resequencing ; the code is thus now placed in the
BasicModel.
The list renderer state is then updated after the resequence.
The resequencing and the line edition have been placed in a common mutex to
avoid problems when the user tries to edit a record while the resequence rpc
isn't finished yet.
Setting ir.values for computed fields is useless as the function onchange
in models.py will set to False all the computed fields with a modified dependence.
opw:767942
Purpose: When a user print a report, for the first time, if there is
no default template choosen, the user should choose a
template AND should be able to update company information at
the same time.
The company form have to be simplified.
* The company report form now inherits from the company form
* Removing the Curency from the company view
* The choosen template is now highlighted
* Footer and website are moved to the other column to balance the view
base_vat: Removing the VIES VAT check from company form view
base_vat_autocomplete: Move VAT as the first field to fill on the
company form view
Purpose
=======
- Settings are too complex: too long + too many options that shouldn't be suggested with checkboxes
e.g. twitter roller is now suggested as a new snippet to install from website editor
google maps, slides, forum, etc. should show up in the apps store
- When saving the page I expect to stay in the settings -> no redirection to homepage anymore!
Specification
=============
See task 33620
The commit 8749410b10 corrected the way the iframe was rendered to display a video in v9.0.
In v10 though, the html sanitizer is a bit more severe and cleans data-src attributes, preventing the iframe to have a src
This commit works around that and allows the src of the video to be saved in db
OPW 761424
closes#19125
Steps to reproduce the bug:
1. Import a bank statement with the shown dateformad DDMMYYYY (without headers)
2. Specify this date format in the advanced options
3. Try to find the date column to assign.
Bug:
The date format is not suggested for the fields with format DDMMYYYY.
opw:769118
Hiral Bhavsar