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%-).
When the user converts the lead into an issue, an error occurs: "Form
view couldn't be loaded". This is because the web layer tries to refresh
the data related to a deleted record.
Instead of deleting the lead, we archive it.
opw-670259
When a lead/opportunity is created, the probability must match the
probability associated to the stage, as introduced in commit b2733391.
However, the call to `_get_default_stage_id` looses the context, which is
an issue since the method `stage_find` will inspect it in order to find
default values to build the search domain. The result is that the manual
call to `_get_default_stage_id` might return a different result than the
automatic call from `get_default`, and therefore the probability does not
match the stage
opw-669960
When the user click on save, 'is_valid' is called on each field.
The o2m test all sub-field (apply modifier and check value).
But, if a modifier change the read-only attribute, the field is reinitialized and call 'render_value' without check 'no_rerender' value.
The relational fields call the db in render_value, and the x2m is invalid because a request is pending.
(change X2ManyListView to keep the 'no_rerender' initial value)
opw-653120
The alternate languages links set in the page `<head>`
were not translated in each language, but within the language
the user is browsing the website.
This leaded to SEO referencing issues, as these links leaded
to (30x) redirections if followed, to translate the URL slug
within the new current language.
e.g.
`/fr_FR/shop/product/bose-mini-bluetooth-speaker-7`
automatically redirected to
`/fr_FR/shop/product/mini-haut-parleur-bluetooth-bose-7`
And it was the first link which was displayed as alternate link
when being in another language than French, while it should
be the second (to avoid the useless redirection).
opw-669979
When we render the payment screen the current value of the current
paymentline is rendered to a string using
Paymentline.get_amount_str(). This conversion always rendered numbers
with a decimal separator of '.' because it just used
Number.toFixed(). This used to be fine but
5a10903e9b made the POS adhere to the set
decimal and thousands separator. Because of this, the POS now has to
parse the input with web.parse_value() which takes into account these
separators. When parse_value() parses a float it first deletes the
thousands separators and then replaces the decimal separator with '.'
before it gets cast to a Number.
In German (and other languages), the '.' is used as a thousands
separator which means that it will get deleted by parse_value() so
you'll end up with '12.34' being interpreted as '1234'. Because of this
it is important that we ensure that the default value that appears in
the input uses the correct separators.
The aforementioned issue only occurs when the user changes the default
value in the paymentline. Only then does a conversion take place from
String to Number. So just clicking on a payment method of type 'Bank'
and validating it would work fine, only when the payment amount was
updated would the issue occur.
Fixes#9395Closes#10952
note: this should not be forward-ported to >8.0 because later versions
use the rewritten payment screen which is completely different from the
one in 8.0.
When delivering a delivery order (`stock.picking.out`),
which generates accounting entries
e.g. thanks to the real-time stock valuation,
the date of the move set was the UTC today date, while it must
be the user's today date, using the timezone passed in the
context.
This prevented the delivery of the `stock.picking.out`
when the `Check date in period` boolean was checked
in the stock journal, and the user date is in the previous
month compared to the UTC date, as the date set on the move
entries were not in the selected period for these move entries.
e.g. When the user timezone is UTC -8, and his current time is
2016-02-29 18:00:00, the UTC date is 2016-03-01 02:00:00, the
period chosen is February (correct), but the date on the move
entries were set to 2016-03-01.
opw-670820
That will avoid to have the _logger.info at each print.
Now we fallback on lang of company and not en_US by default
If report lang was 'doc.partner_id.lang', we was looking for
lang code == 'doc.partner_id.lang'
instead of
code == eval('doc.partner_id.lang')
=> code == 'de_DE'.
Therefore, the template could be seen from
the Discuss module, when clicking on "Send Mail",
but, when attempting to use it, it failed
(as it was not applied on the right model).
opw-670546
The intrastat report period should match the accounting period of the
invoice. This might not be the case if the user manually chooses an
accounting period which does not match the invoice date.
opw-668827
When an analytic account is specified in the reconciliation, the
analytic lines are not created. This is because the account move is
posted before the account move lines are actually created.
Fixes#10951
opw-670110
In an environment where multiple database are available the company_logo
controller in the web module will return a placeholder logo (the Odoo
logo) if it can't figure out what db the request belongs to. This logo
is used on the ESC/POS receipts.
Because we load the logo with an anonymous CORS request there is no
authentication on the request. This is necessary because the POS tends
to not be served over HTTPS whereas the rest of Odoo is. Without this
crossOrigin attribute we could potentially end up in a situation where
the canvas is considered tainted by the browser which would prevent us
from extracting the canvas' data with toDataURL(). So removing the
crossOrigin attribute is not an option, specifying the db is the next
best thing.
opw-670471
note: in >=9.0 session is a variable defined in the js module instead of
a property on PosModel, so 'self.session.db' should become 'session.db'.
Commit 516b1a6c72 fixes a bug with action buttons not being displayed when they
should in dialogs. However, it makes the assumption that either $node or
this.options.$buttons exist, which is not always the case (e.g. dashboard).
This rev. moves that logic out of the views to the view_manager, and protects
the call of empty() on this.options.$buttons.
Moving a whole package (option "Allow moving packs") results in a
traceback. Indeed, the method `_get_all_products_quantities` returns
product ids, while `_create_extra_moves` expects browse records.
opw-668180
When counting the 'activities' on each opportunity/lead,
this view only considered messages with a subtype that
matched the subtype of a specific crm.activity.
This was not consistent with the crm.opportunity.report
which counted *all* messages on an opportunity as
"activitiy entries".
The latter is considered better because any entry,
(even automated one for tracking field value changes
or automated system responses) corresponds to an "action"
taken on that record.
This patch makes crm.activity.report consistent with
this decision: it will now count all messages.
+ also convert the incorrect `left join` to a plain
[inner] `join`, as we don't want deleted leads to
appear in case orphan messages were left around
(which should not happen anyway).
Joren Van Onder
