meaningless entries like
` Checks that the bundle's cache is working, i.e. that a bundle creates only enough
become
` Checks that the bundle's cache is working, i.e. that a bundle creates only enough ir.attachment records when rendered multiple times
see https://docs.python.org/2/library/unittest.html#unittest.TestCase.shortDescription
An issue could arise if a preprocessed stylesheet asset is present
in multiple bundles: the first bundle will cache a version of this
file (identified by its url) and the second one will cache another
one. The next time the first bundle is rendered in debug mode, it
will use the last created record of the asset.
This could lead to design issues as, for instance, a less asset
could change according to another less asset included in the bundle.
We fix this issue by adding the xmlid of the bundle in the url's
asset. This fix another inconsistency as the compiled version of
an asset is reachable with an url that is not dependent of its
bundle, so if the asset is present in multiple bundle it could
return different values.
Note: this only concern the debug mode
`default_search_product_id` with several ids simply can't work.
The only way to do it is using a domain in the action.
Anyway, this is unlikely that the user would like
to remove the domain (which is the main interest
of using a filter, the possibility to remove it), as
this will display all sales orders lines, whatever the products,
all mixed up. This is not super-useful.
opw-671022
Finally add support of CIDs in incoming emails. Inline images are recognized
and added as attachments. Image links are updated from src=cid: to src=link
using the /web/image controller.
It has been decided to keep the image in atttachments instead of putting them
in base64, like proposed in various PRs. Indeed we prefer to store this data
into the attachments instead of directly putting it in the mail_message table.
Moreover this enable the display of attachments in the chatter and record views.
the messages in a thread were previously rerendered every minutes to
update their timestamps. This commit only update the timestamps, not
all the message. This will allow us to keep expanded/folded state in
messages without collapsing them every minutes.
[IMP] mail: add read more/read less support client side
Messages are cleaned up and tagged server sides, with a attribute
data-o-mail-quote. This commit replace their content with a clickable
read more link, which toggle its display.
Quote detection is now done in the sanitizer itself. It tags nodes that are
inside quotes (signature, text quotes, email quotes). The purpose is to remove
html_email_clean and have all the html cleaning / sanitizing inside a single
function. When a node is tagged, data-o-mail-quote is set on the node.
This attribute is added in the whitelist of valid attributes for the
sanitizer.
[REM] Support of shortening messages. The read more / read less will only
display or hide detected quotes and signatures. Shortening messages above
a given amount of characters is not supported anymore. Indeed it adds much
complexity to the sanitizer without adding much value to the result. The
primary purpose of the sanitizer is indeed to remove noise and unnecessary
content.
[TESTS] a lot of test are not necessary anymore, as read more / read less
display will be moved in the front-end and as the shortening has been
removed.Tests have therefore been cleaned and simplified.
[DEMO] mail: small demo update to include a bit quote detection
Purpose:
The field date_deadline is a date field (without hours:minutes:seconds)
The customer is tempted to put the task deadline under hours, which is not
feasible
So in the calendar view for task, set the "month" view by default
instead of the "week" view.
when using a journal with 'Group Invoice Lines'
and issuing an invoice with foreign currency with more than 1 line
(of the same product, or no product),
the amount currency in the journal item
associated to the merged invoice lines was wrong.
It took into account the `amount_currency` of the first line only,
ignoring the `amount_currency` of the remaining merged lines.
opw-670972
Closes#10375
When creating the account translations using the account template translations
read it without the environment language.
Otherwise, when the translation is created, the content of `element.name` (the
source term to translate) might be in a different language and already
translated.
This was introduce during the migration at the new API where previous code did
not propagate the context (probably by accident).
Up to this revision, barcodes set in reports are generated
using the controller `/report/barcode`,
using a `img` HTML tag, e.g. (from `report_location_barcode`)
```
<img t-if="not o.loc_barcode"
t-att-src="'/report/barcode/?type=%s&value=%s&width=%s&height=%s'
% ('Code128', o.name, 600, 100)" style="width:300px;height:50px"/>
``
This `/report/barcode` route is set as `auth='user'`, meaning
the route can only be accessed by signed in users.
When wkhtmltopdf prints a report containing such a barcode,
it calls this `report/barcode` route, making sure to pass
the request session in the cookies, so wkhtmltopdf
uses the same session than the one of the user. This is
needed, as only users can access this `report/barcode/` route.
This session is passed in `report.py`, in the method
`_run_wkhtmltopdf`, thanks to the --cookie wkhtmltopdf
parameter.
Nevertheless, if a report is printed through the website
front-end, as public (without a signed in user), the request
session is not associated to a signed in user, and therefore
the route `/report/barcode` refuses the access / redirects
to the login, making it impossible to print a report
containing a barcode without being signed in. This even
if the report is printed as `sudo` through a controller
(as this is the session of the not signed in user which is passed,
not a session associated to `sudo).
Fixes#10621
opw-667797
Before this commit, the only way to translate a chart of account was to install
the language (if present in 'spoken_language' field on the chart of account
configuration) **before** the installation of the chart of account.
This commit loads the translations of the chart of account at the installation
of the language too.
To avoid recreating translations at each update of a language, skip if the
language is already installed.
This means than, to benefit from the fix, already deployed instances should
remove (after de-activating it) the language and reinstall it to translate
existing chart of account.
opw-670327
Closes#11091
When a specific SMTP server is set on a mail template, it is never used
when the mail is sent. There are two reasons:
- `mail_server_id` is a read-only field set by an onchange. However, a
read-only field is not sent to the server, so the information is lost.
- The information is stored in the context of the object `Mail`, but it
is never used. Moreover, when the method `message_post` is called, the
`Mail` object is not used to post the message, so the information is
lost again.
The fix includes two parts:
- the `mail_server_id` field is not read-only anymore. Actually, there
is no reason to make it read-only.
- the information is stored directly in the mail values and used at the
appropriate moment.
Fixes#6554 (from v9.0)
opw-669958
In Odoo 7.0 & 8.0, this was possible to translate
a field label, from `en_US` to `en_US`. It was
used as an easy way to change the fields label,
instead of creating an inherited view changing
the string attribute of the field everywhere it was needed.
This was no longer the case in 9.0,
following the revision 9593a29.
The translated terms for `en_US` have been
excluded, for performance reasons
as it was considered not possible to have
translated terms for the `en_US` language.
The fact is, this is very possible: Nothing
prevents to add a translated term
in `en_US` for a translate-able field,
as this is the case for the fields label,
as mentioned above. This field is then
used as the display value instead of the source
term when being in the `en_US` language.
Besides, the above revision was mainly to
give the possibility to sort a model records
on a translated field, using a join on the translations
table. It was then considered that the join could
be avoided, in the case where the user language was `en_US`,
for performance reasons, but, as this is possible
to give another value to the field value trough
the translations, it should actually be done, even
for the records sorting.
opw-670814
Test to bind save and discard buttons of an editable tree view are done
only once when initializing it.
But if the view is by default grouped at the beginning, it will be then
"not editable" but only removing the groupby will change this.
So this commit add a case so if the view is grouped when initialized,
the buttons are always bound.
closes#11198
opw-666794
It looks like reportlab doesn't handle well
UPC-A barcodes.
As UPC-A barcodes became EAN13 barcodes when
adding a `0` to the beginning of the barcode,
and the render is the same, we ask reportlab
a EAN13 barcode type when a UPC-A barcode is asked,
making sure to add the `0` automatically first.
From Wikipedia:
```
The EAN was developed as a superset of UPC,
adding an extra digit to the beginning of every UPC number.
[...]
the original rules for UPC are treated as a '0'
if read as EAN-13.
A UPC barcode XXXXXXXXXXXX therefore is the EAN-13 barcode 0XXXXXXXXXXXX.
It is possible to prefix a UPC barcode with a 0;
they become EAN-13 rather than UPC-A.
This does not change the check digit.
All point-of-sale systems can now understand both equally.
```
opw-670560
In the POS we use a touchmove event listener to stop undesired
rubberbanding (in Chrome.disable_rubberbanding()). Elements which should
be scrollable by touch should have the touch-scrollable class. The
receipt screen is obviously one of those, because otherwise you won't be
able to scroll down if you have a long receipt.
opw-670899
When a bank account is set within another currency
than the company currency
(the currency of the journal is set and is different
than the company currency),
the balance displayed was the amount within the company
currency, instead of the amount within the bank account
currency (despite the fact the currency displayed
was the one of the journal).
opw-670815
I'm not sure why the serial timeout is so aggressive, but I assume there
is a reason for it. During probing however, we shouldn't use such an
aggressive timeout because if we miss the device during initial startup
we'll never find it since we only probe devices once.
Style attribute is now parsed and sanitized. Only a while list of accepted
properties is kept. The behavior is implemented directly in the cleaner
itself. As there is no easy possible inheritance, the styling cleaning is
appended directly after the legacy processing in __call__.
The styling sanitizer is called only if the style attribute is kept. If
the sanitizer is called with strip_style=True, the styling is removed
and therefore no sanitizing is performed.
Tests about html fields have been updated. Indeed the styling is now sanitized
and the test was not correct anymore, as the test html was stripped. It now
contains styling that is kept. The strip_classes is also tested.
Do not strip class by default on html fields, this was an error. Currently
only mail_message body field should not contain classes. Indeed as external
content can be stored through the mail gateway we do not want to keep the
classes.
Convert the domain to display only the sale / purchase
taxes in the taxes list to a default filter doing the same thing,
but which give the possibility to remove the filter
and see taxes with the scope `None`.
opw-670737
Do not try to keep frames as they are already removed. Indeed tag_to_kill contain
the frame tag. This parameter has precedence on the ``frames`` parameter of the
cleaner. It was therefore unnecessary.
Added the support of strip_classes, like the already existing strip_style
parameter of html fields.. This parameter is missing but allow full
customization of html fields.
Also fixed the call to the sanitizer in fields. Indeed the strict mode is
set to False. When not in strict mode the classes are never stripped whatever
the value of strip_classes.
Sanitizer is now called always in strict mode to ensure the sanitize process
is correct and really take into account strip_style and strip_classes.
This fix is done in master due to possible side effects and possible behavior
changes that are not welcomed in stable versions.
After plugging in multiple identical serial to USB interfaces, only the
last one will be available under /dev/serial/by-id/ because they'll have
identical IDs. Instead use /dev/serial/by-path/ which does not have this
issue.
We support the Mettler Toledo scales which have their own built-in USB
to serial interface. Due to continuing issues with that built-in
interface we will also support the scale configured in raw RS-232 mode
which seems to be more reliable.
This means that in order to connect the scale you'll need a third party
USB to serial interface (unless you have built-in serial interfaces, but
the POSBox doesn't).
The main difficulty this poses is that using this approach we cannot use
the name of the interface to find the device. When using the built-in
interface of the scale the interface would identify with an ID
containing 'mettler' and 'toledo'. When using a third party interface
the ID will instead contain information about the third party
interface. To fix this we use a probe-based approach, probing every
available serial interface until we find one that returns a response to
our probe. This approach will work with both third party interfaces and
the built-in interface of the scale.
Contrary to probe-based approach used in hw_blackbox_be this one is
slightly more complicated because hw_scale is written in such a way that
it is 'plug and play', which means that as long as the module is running
it will continually try to find a scale. This is fine, but we don't want
to keep sending probes to eg. Fiscal Data Modules, which could lead to
issues. Therefore we will only probe every device once. When we lose an
existing, confirmed connection to a scale we will however keep retrying
to connect to that particular device.
Before this rev., editing the subtypes of other followers was only possible if
the current user already opened a record of the same model of which he is
himself follower.
- extended_chat_window feature in its own files: as it is only available in the
backend, we don't want it in the frontend assets (which contain the 'basic'
chat_window)
- move followers feature in its own files
- creation of the 'mail.utils' module in utils.js
- creation of systray.less to define the style of the mail item and dropdown
in the navbar
- use of chat_manager's search_partner function in PartnerInviteDialog
- some code linting
When loading a form_view with the follower widgets, an RPC was performed to get
the followers info (name, email...), and if the user is one of the followers,
a second RPC was done to retrieve the subtypes.
This rev. batches those two RPCs. Also simplifies read_subscription_data() as
it is now always called with a follower_id.
A few code refactoring as well.
When printing a BOM structure using a variant,
the specifications of the variant were not
displayed in the BOM Structure lines,
making it different than what can be found
in the BOM structure form, and therefore
making it impossible to know which variant
has to be used for this BOM structure
from the report.
opw-670448
When printing the production order, the name
of the product did not include the variant
specifications, making it different then what
is displayed on the production order form,
and preventing to know which variant was produced
for this production order.
opw-670448
Commit 7270780 removed the default for the 'template_id' field,
but other modules assumes SOs are created with it. If not, you
cannot view the quote in the frontend and if you change the template
afterward, you lose all the lines currently in the quote. This commit
restores the behaviour from 9.0.
Since the commit that removed them did not mention why it did (not
even remotely), I'll assume it was unintentional and/or not thought
through.
This commit introduces "Sub-task", a concept remotely similar to
the "delegated tasks" available in version 7.0, but covering a
more specific and narrow scope.
Activating Sub-tasks
--------------------
Sub-tasks are made available within any project by configuring
a "sub-task project" in the project settings. This feature is
considered low-level and technical, and only accessible with
"Technical Features" enabled.
The "sub-task project" may be the project itself.
Using Sub-tasks
---------------
Conceptually, a sub-task represents the allocation of a part
of the scope of its parent task. Multiple sub-task levels
are possible.
Once activated in project settings, a new "Sub-tasks" smart button
will appear on the task form, giving the option to view and
create sub-tasks. In addition, a new field "Sub-tasks Hours" will
appear next to the other computed "Hours" fields, representing
the total hours allocated to sub-tasks.
(Technically, the sum of the maximum between the planned hours
and spent hours of all sub-tasks, with spent hours always used
when a task is closed)
These sub-task hours will be dynamically subtracted from the
remaining hours of the task, and will therefore affect the
task's progress as well.
Upon creation, a sub-task will inherit the link to the
original sales order and procurement from its parent task, and
will by default be assigned to the "sub-task project" set on
the project of the parent task.
Enhancement
-----------
The kanban view for tasks will now display a color-coded label
with the number of remaining hours, whenever the percentage
of remaining hours is below 20% (orange=20%-, red=1%-).
Simon Lejeune