Task 32132
Currently, importing image requires either uploading them
one-by-one (after the initial import), scripting that upload, or
converting all images to base64 and putting that in the import
file (leading to a huge unreadable file) before actually doing the
import.
This is problematic for non-technical users, especially when they're
deploying or synchronising e-commerce products.
This change matches URLs in image fields and goes to read the URL &
load that as image data. It performs the read inline which is reactive
but means the imports will be very slow (wallclock) as each URL will
have to be fetched and encoded.
Configuration: via config file only
* import_image_timeout (seconds, default 3), initial connection timeout (not
overall file download)
* import_image_maxbytes (bytes, default 10MB): maximum image size to
download, checked before download (Content-Length) and validated
during (in case Content-Length is missing)
* import_image_regex (str), matches field content as "probably an
image", by default checks that the field value starts with
http|https and ends with an image-type extension (e.g. bmp, png, jpg)
Hard Limits:
* only works on fields actually called "icon", "image", "logo" or
"picture"
* the image can't be more than 42MP (checked after all data is
downloaded)
Hooks:
* _can_import_remote_urls (on res.users) checks whether the current
user is allowed to import via URLs
* _import_image_by_url (on base_import.import) performs the actual
download, could be overridden to store urls to import and
batch/queue the actual imports
When editing a translation on the website, if the user copy/pastes directly in
the web editor, then the html formatting is also copied.
Since the translation matching takes the html code into account when matching
the translations, this breaks the pairing.
When trying to save, the backend function validating the new translation thus
fails and return a server error.
However nothing was done with this error, and the user just witnesses that
saving doesn't work (unless he opens the console to notice the rpc failure).
We now display an alert dialog that notifies which tranlation causes the error.
opw 1862784
Since af9d6b86a1 and
5a57c29ff2 , python3.7 can be used to run
Odoo. This commit ensures that python3.7 compatibles versions of gevent,
greenlet and lxml will be installed without breaking compatibility with
Debian Stretch packages versions when using the Debian packaged Python.
Closes#25841
In some case, we want to have a different style for activities that
require attention for users. Sometimes activities should attract the
user attention with actions to perform that are important.
This commit introduces a decoration option on the activity type. By default
no decoration is done. However decoration type can be set to warning or
error. This triggers the related bootstrap alert classes.
This commit is related to task ID #1860833. Closes#25479.
If notification layout used to encapsulate message send by email is not
found simply send emails without layouting instead of skipping it. We
should not avoid information to be send.
Commit e38ed7c780 moved code related to purchase, stock and
purchase_stock in order to clean module dependencies. However probably due to
some wrong manipulation notification layout was reset to an old removed
layout. This commit fixes it.
Have two invoices
Make a bank statement with one line, which amount is:
Amount[Bank] < Amount[Inv1] + Amount[Inv2]
AND
Amount[Bank] > Amount[Inv1]
Click on on the reconcile button on the form view of the bank statement
On the reconciliation widget:
Click on the first invoice to fully reconcile it with the payment
Click on the second to partially reconcile it with the payment
Before this commit, there was no way to let the second invoice open
and partially reconciled.
The only possibility was to make a write-off
V10.0 allowed to to do such a flow
After this commit, this use case is dealt with again
OPW 1864689
closes#25721
When editing his post, a user can modify the tags even if he doesn't have
sufficient karma to do so.
Since the backend raises an error, it sends the user to a 403 forbidden page.
opw 1866019
When checking if tags had changed, a missing .ids made it that a recordset was
compared to a set of ids (integers).
As a result, to make an edit the forum would always check that the user had
sufficent karma to retag, even if it was not needed.
opw 1866019
Task 40692
Various changes to import/export (mainly) UIs:
* default to excel & "full" (non-import-compatible) export
* auto-detect encoding of CSV using chardet
* remember column -> field mapping after having imported a file (useful
for repeated imports where auto-matching failed)
* better handle localised booleans & column names
* automatically select source list view's fields when exporting
* better integrate import templates feature and add a number of templates
For records having multiple translated terms per field (like html fields),
it was possible to have duplicated entries when synchronizing existing
entries with new ones.
This commit will replace the delivery carrier list choice by a single and more
discrete line bellow the billing/shipping section when there is only one
carrier available.
opw-1832976
In python 3.7, async is a reserved keyword.
Using it in a method signature produces a syntax error.
Replace by an argument async_load and catch the previous calls in a kw for
backward compatibility.
Log a warning on public methods.
The **kw can be removed in v12 and officially deprecate the 'async' parameter.
Fixes#25578Closes#25783
Enterprise counterpart of this commit: https://github.com/odoo/odoo/commit/762adedece1c6c2b97b282348659c1b39b988d24
In enterprise the commit will also remove most of the features of website_quote_subscription because they became obsolete with the ability to create sections.
Indeed the feature was to automatically regroup recurring subscriptions in a "section" at the bottom of the documents. Now if the sale persons want that behavior they can just create an actual section.
Task #53996
PR #2276
The goal is to be able to more easily create section and notes on sale order, invoice, and quote.
================================
Problems of the existing feature
================================
The problematic part in the existing feature was that the same section had to be defined again and again for every line, instead of being defined only once where it needed to be. There was also no easy way to move them. Those concerns are solved here.
Moreover, due to the complexity of the feature, it was hidden by default, requiring a setting and multiple overrides. The new feature is simple enough that it will always be present.
==================
New implementation
==================
Sections are lines solely used for display purpose, there is no business logic attached to them. They will show as a nice header at the top of the section, and a subtotal at the bottom of the section.
We also take the opportunity to add notes, which are just like sections except they are displayed differently and don't include a subtotal.
=========
Reasoning
=========
We decided to implement it this way, as opposed to creating a proper section model, because it creates less changes in the code.
Creating a intermediary section model between the sale order/invoice/quote and their lines would have required to rewrite the entirety of the code associated to them. It would also have required to create a new JS widget to handle on the same view a double-level One2many (or a One2many + group by).
The current solution is much easier because it just requires adding 2 buttons, 1 simple field on the corresponding models which even has a NULL default value, and making some business checks (don't apply business to section/note).
We tried our best to impact as less as possible the existing models. Notably we didn't want to add any extra field if this was avoidable. This also makes the migration easier.
No matter the implementation choice the views/reports had to be updated to display the sections and notes correctly, which has been done.
===========
Limitations
===========
The current solution has several limitations:
* since the sections don't have business logic, it's not possible to make any reporting based on them
* any business related to sections has to be computed on the fly by browsing in order all of the lines, notably the subtotal has to be computed on the fly at every display
- when sections are moved (drag&drop) on the back-end, the following lines that are part of the section are not moving with the section
===========
Technically
===========
The commit will:
* update the models to add the display_type field (along with related sql constraints to guarantee integrity)
* add new buttons at the bottom of the lists to allow creating section and note, along with the existing add a line/product button
* add some business checks to not apply business to section/note (product_id and account_id became non-required fields)
!!! The most likely cause of potential bugs introduced in this commit would be to have forgotten to add those checks on some places where they would be needed. This is tedious to check but fortunately easy to fix.
* update the views to display sections and notes correctly, also made various improvements/fixes to those views (notably to apply B2B/B2C setting more consistently)
!!! This is the second likely cause of potential bugs: if the updated views are inherited in a way that is not compatible with the changes. Or if we forgot to apply the changes to some other views. Again this is tedious to check but fortunately easy to fix.
Task #53996
PR #25209
Since sale depends on account and not the other way around, it's better to have this setting inside account.
Functionally it will allow the user to benefit from this setting also if he uses only invoice without sale.
Technically it will allow us to remove all of the overrides that were previously necessary for this setting.
While we moved the setting, we also renamed the different variables so their name better convey their meaning.
PR #25209
The default "add a line" button creates a new line with the default values from the model. Sometimes we want to create a new line with different default values (or more generally a customized context), which is possible with this commit. Moreover it is possible to create multiple buttons for multiple default values/contexts.
This works both for in-line creation ("editable=") and dialog creation.
The new tags are:
<control> defines custom controls for the current view.
Does not support any attribute, but can have children:
<create> adds a button to create a new element on the current list.
This makes sense when the parent tree view is inside a One2many field.
If any create is defined, it will overwrite the default "add a line" button.
For more information and example, have a look at the Views documentation.
Technically, the commit will:
- parse the new XML tags (+ add appropriate validation)
- display the buttons based on the XML
- on button click/keyboard: pull up the additional context information from the button event up to the default_get
- add unit tests
- add documentation
PR #25209
Currently, using the shortcut "tab" inside a list will crash if the list has no input field (ex. if it has only a textarea field).
This commit prevents the bug.
Also moved the test for the orderedResIDs crash in the correct module.
PR #25209
Multiple currencies in the same POS have never been
supported. However, before ac89783d2f it
was possible to load a POS with a currency different from the
company's currency through the sales journal.
This re-introduces that option by manually converting to the default
pricelist currency if it's different from the company currency.
The currency conversion implemented here is based on (and should be
identical to) _convert on res.currency.
opw-1863047
When trying to click on "Mark as Done" on a MO with raw materials in a category
with automated fifo valuation, it raised in some a case (in function called
"_prepare_account_move_line") a user error saying:
"The cost of the product P is currently equal to 0. Change the cost or the
configuration of your product to avoid an incorrect valuation"
This problem coming from the fact that in some cases, self.price_unit was
equal to 1.04166666666667e-06 instead of 0
opw:1862153, 1866692
Atul Patel