Put the browser in timezone Sao Paulo (Or like West of UTC)
Trigger the autocomplete (and the subsequent search) on a date field
by writing a date (in the locale format) in the search view
Before this commit, the domain sent to the server contained the date as the day
**before** the one asked for in the input
This is because, the string input is parsed and gives:
input = 12/02/2018
When creating the moment object:
> since there is no explicit time, moment will interpret it as 12am (midnight)
> We force moment to consider the string as being UTC (function: moment.utc())
> the moment contains, as output the time ** 2018-02-12T00:00:00 UTC **
When getting the facet value for making the domain
> we call toDate on the moment object, which, according to the browser is UTC and will
be converted to the locale timezone before formatting
> And the domain will use the date 2018-02-11T22:00:00 Brazil/SaoPaulo
which gives the day before the one we asked for
After this commit, this issue doesn't arise, because we don't convert the moment into a Date,
and we directly format that moment into a string
OPW 1903224
closesodoo/odoo#28689
The NotificationService has a side effect: it adds a div inside
document.body. We could implement a cleanup mechanism for services, but this
seems a little overkill since services are not supposed to be destroyed anyway.
closesodoo/odoo#29099
This commit adds a warning for common causes of mistakes, while running
the JS test suite. It is possible to lose a lot of time trying to make the
tests pass if one does not notice that the browser window is not zoomed at 100%.
Maybe this warning will help someone in the future...
closesodoo/odoo#29021
Reorganize the javascript to use conventional website widgets, rpc calls, classes, ... This will allow to better improve, fix and extend the existing behaviors. This is also a first step towards automatically testing website features more correctly.
This work was started with https://github.com/odoo/odoo/pull/27719closesodoo/odoo#28404
Since commit 2bd10fa757 when the user specify a MO the
unbuild use the existing moves raw and moves finished in order to create the unbuild
moves. In this case the bom_id and the product_id is not needed since we don't generate
unbuild move from the BoM
This commit is related to task ID 39843.
The purpose is to help the user if he has difficulties
to know the purpose of a field. The field for tracking
was named lot but it is also used for serial number. That
could be confusing for the end user. Also rename source as
source location in order to be coherent with destination
location
This commit is related to task ID 39843.
Review the JS reorganization made by direct parent commits and do more
to use our defined JS conventions. Also simplify JS which can be
obviously improved.
Impacted modules: sale, sale_timesheet, sale_expense
The purpose of this commit is to remove harcoded list of xml ids that
are not defined in the module 'sale'. This commit brings a new
implementation of the feature (hiding re-invoice policy on product
form view, depending of multiple user groups). The approach is more
modular and easy to extend than the previous one.
Therefore, this commit is completely technical and does not change any
functionnal behavior.
Task-1896095
closesodoo/odoo#28786
Modifying a source term in an XML/HTML translated field can lose translations
if the same term is translated in several languages.
closesodoo/odoo#29082
Purpose : This module was allowing to quickly create tasks from
leads. It is now considered as useless, and an activity should be used
instead. We bring another module crm_helpdesk in enterprise to convert
leads to helpdesk tickets, which appears more useful.
Closes#28425 Task-1867574
Before this commit, it was not possible to effectively limit the available
products when a company had several POS with different product offers.
This commit allows limiting the available product categories for a single POS.
Now, a company can serve different POS with different product offerings.
Anecdotal Note: This was especially annoying as the POS only shows 100 products.
If those happened to be the products not served by a signle POS, the only work
around was using the search bar (on a tablet?!?)
closesodoo/odoo#28393
There are two different icons on bom lines to distinct the ones having
attatchement links and the ones without. But those icons are not very
explicit and so we set the same icon for all lines and the number of
documents next to it.
TASK-ID: 1878242
closesodoo/odoo#26625
There is no company_id field on stock.move.line and it is so impossible
to restrict easily the access rights on move lines (except by passing
through stock.move, but all stock move line don't always have a
stock.move)
To resolve this we've added a field company_id on stock.move.line, and a
constraint to force it having the same company_id than the one on stock
move.
Task ID : 1905232closesodoo/odoo#28575
Until now, the volume measure displayed on the product form was only in
m³. We now allow to choose between m³ and ft³.
So, we add volume selection field (m³/ft³) on general settings and it will
be display on product and product variants form view as configuration.
We also Remove tooltip from weight and volume field.
And display weight (kg or lb(s)) in product and product variants form view correctly,
because currently weight didn't display on product form view before save the product
but after this commit weight will be display.
This commit is related to task ID 1869002.
closesodoo/odoo#26542
Fixing it directly by commit since there is no es_AR on transifex.
The issue of the ticket has been solved by transifex, this is for
another similar issue that has been found.
opw-1907924
closes#28929
In the extended composer, we focus on subject when adding a mention in
the body. Focusing in subject is wanted at the opening of the composer,
but not when adding a mention.
opw-1911566
closes#28910
The "add" button shown in the outstanding credits menu in the
button right corner of a payment wasn't shown in green like the
other clickable elements.
opw-1907342
closesodoo/odoo#28908
In the following commit (https://github.com/odoo/odoo/commit/744de4ee1cec5e43aa77ac3eccc7a9b1224f8fa1) we introduced some floats as keys
to Selection fields (namely request_hour_from and request_hour_to)
This lead to the ORM creating a column of type `int4` to store this
field which rounded the values.
In order to repair that faulty behaviour we use negative integer values
for the half hours, which is then transformed back into a float in the
code.
closesodoo/odoo#28877
Steps to reproduce the bug:
- In the Manufacturing App , enable Work Orders and Quality
- Configure your products,BOM and Routing
- Create steps in routing with type='Register Consumed Materials'
Bug:
When you finished your Work Order operations it displayed "False" value in
the "Finished Steps" tab instead of the uom of the finished product.
Technically:
The function "record_production" unlinks the temporary stock.move.line that can
be linked to a quality.check. So the component_uom_id of the quality.check could not
be found when computing the field 'result' on model "quality.check' with function "_compute_result".
opw:1909768
closesodoo/odoo#28865
When we print or post_message of an invoice it is set as sent.
But when we multiprint, we do not use each invoice post_message but
create directly mail.mail then send them in batch.
Thus the invoices are not set as "Sent".
With this change we make a special case.
opw-1910937
closes#28852
Purpose
=======
As we try to open a mail.compose.message on a model that doesn't inherit
from mail.thread (Mimic a cowboy yellin' "Yihaaa" while shooting into the air
with one revolver in each hand).
Specification
=============
The only way to fix this issue while keeping the feature (Open a
mail composer) is to open the mail composer in mass_mail mode and
to remove the model on which it should be called.
The template won't be rendered in the mail composer but will
be rendered when sending the mass_mailing obviously, while avoiding
the unavoidable traceback when clicking on the 'Send' button
closesodoo/odoo#28849
The gengo module is used for automatic translation, if you try to
uninstall the module, at some point the required models/fields of
gengo no more exist but the module is still in use by odoo for
every translation.
This commit fixes the problem by disabling the gengo translations
when the system is installing/uninstalling a module.
opw-1906293
closesodoo/odoo#28806
The "Get authorization code" button in the General Settings >
Integrations > Google drive was not correctly rendered on firefox.
This PR fixes that bug by correcly rendering the button, it has
been tested on both Firefox and Chrome
opw-1907644
closesodoo/odoo#28672
- The value returned by the method `_portal_ensure_token` is False due
to a cache issue.
The value is generated written using the `sudo` environment while in
the current user environment the cached value is `False`.
After generating the value, the cache is not cleared, thus letting the
method return `False`
closesodoo/odoo#28836
Before this commit, we had the following issue:
1. Open two tabs A & B.
2. Receive a message from a channel in tab A.
3. Mark it as read in tab A by clicking on the
chat window of the channel.
> The unread counter is correct in tab A: no
unread messages on this channel, and the
messaging menu counter has been updated.
> The unread counter is not correct in tab B:
it still has unread messages on this channel,
and the messaging menu counter has not been
updated.
The issue was caused by not notifying the updated
unread counter to the widgets when receiving the
'channel_seen' notification from the longpoll.
It was working in tab A because this is were we made
the action, so that it already marked messages as
read without waiting for the longpoll response.
However, Tab B has to wait for the longpoll response
to update the unread counter. It was updating the
counter, but it was not notifying the widgets.
This commit fixes the issue by letting the widgets
know when the unread counter has been reset.
Task-ID 1911239
closesodoo/odoo#28833
Fine-tuning of commit: d60f2ab0e2
Which applied when the next action was to create a new activity.
However the problem is also present when the next action is to send an email.
We extract the logic in a new private function to share the code in both cases.
opw 1904156
closesodoo/odoo#28819
On save, the editor will ask to parent widgets if something needs to be
done first. The website navbar will receive that demand and asks to its
action-capable components to do something. For example, the content menu
handles page-related options saving. However, some users with limited
access rights do not have the content menu... but the website navbar
expects that the save action is performed. So, this empty action is
defined here so that all users have an 'on_save' related action.
This was only happening since 12.0 as 'on_save' actions were introduced
there to save page-related options.
closesodoo/odoo#28810
Transfer accounts created for payment acquirers was ignoring the prefix of the main transfer accounts and was always creating accounts with code 000001, 000002, etc.
The reason is because the method was called on an empty recordset
closesodoo/odoo#28789
Lucas Perais (lpe)