* account,bus, web_editor, website, website_slides, web_tour
This merge fixes most issues where the webclient crashed with
discuss installed in mobile.
These issues occur due to the fact that the chat_manager, now
a service, was loaded after the webclient is instantiated.
The main idea of the fix is to let the webclient register services
that are loaded after its instantiation.
Despite appearances, the desktop mode had also this issue, but
most of the bugs were hidden thanks to the availability of tours
that are loaded after the module mail.
Fix over this commit: https://github.com/odoo/odoo/commit/02ec09cb1c3e2d7bc7968f40c18f2208d7f3f498
In mobile, when discuss is installed, there is a traceback.
This is a consequence on an issue with JS services, where some of them
are not registered in the service provider.
For instance, the webclient (the service provider) was instantiated before
chat_manager (a service), so it was not aware of this service.
To solve this issue, service providers now listen on newly registered services.
Also improving deployment of JS services by not relying on topological sort.
With this commit, any component that needs an instance of the
root widget can simply require the module 'root.widget'. Based on
the context (backend, frontend, iframe), the real root.widget
will resolve to either the webclient, the website root instance, or
the iframe root instance.
This is desirable in order for the tour_manager to become a child
of the root widget, as tours are enabled in any of the above contexts.
This commit is a requirement in order to solve an issue with JS services,
in which there should be only one service provider at any given time.
As the sequence name depends on the requisition type. The name must be
set not when the requisition is in draft but confirmed. In the confirm
state, the type in readonly. The name is also reset when the requisition
is put in draft.
Mail thread now holds a method to replace local links by global links.
Let us therefore use it in mass mailing as it does basically the same
job. Adding base tag is not necessary anymore since there are not
local links or images anymore.
Since notification emails are not mail templates anymore they do not go
through the mail_template.render_post_process() method that converts
local links to absolute links. This means that buttons and images were
not correctly displayed in notification emails. Indeed those still had
local links.
This commit fixes that by moving the method directly in mail.thread and
calling it accordingly when rendering the notification email. Note that
the method has been changed in order to use regex instead of html
parser. It is done based on work already done in mass mailing application.
Indeed using parsers is complex and time consuming and may create
changes in the html structure that are not intended.
Next step in master is to go through various link modifications in
mass mailing module to see how to handle them properly. Maybe.
Notification emails now use QWeb to be rendered instead of jinja-based
mail.template since 2f7593761c. Part of the notification emails was not working
anymore since its syntax was still using jinja. This commit fixes that.
This commit also removes strange ';' that should not be part of python code
as well as an unnecessary variable propagation.
A traceback occurred on the Intrastat list view (Accounting >
Reporting > Management > Intrastat), when the user clicked on a row
of the list. This action only specifies 2 view modes: list and
kanban. When a record is clicked, the ActionManager tries to open
that record in a form view. As the view isn't in the action, this
request should be ignored. Before this rev., this case wasn't
correctly supported.
Static help from xml and python generated help were both showing the new
smiling face, we needed to sort that out.
Python dynamic help now prevails over static help.
Co-authored-by: RomainLibert <rli@odoo.com>
Use case to reproduce:
- Install delivery/batch picking
- Process 2 pickings in a batch.
-> Traceback due to ensure_one.
It happens because the action_done method in delivery is
not multi and batch_picking launch action_done on multiple
picking.
This commit makes action_done in delivery multi.
It happens due to workcenter working hours,
the workcenter is not active during the weekend thus
the productivity loss are not counted in the oee.
This commit removes 2 days to the test date if it is
during the weekend.
Previous to this commit, installing sale_managmenet/account_invoicing
would add some menu items for the `sale/account` module
(which contains all the logic for the sale/accounting flow)
and it would also install sale/account since it's a dependency, however,
horror would strike if one were to go and uninstall
sale_management/account_invoicing: nothing happens!
This is because these "facade" modules don't actually install anything, and
uninstalling an app does not force the uninstallation of its
dependencies, thus the `sale/account` module would stay installed, along with
the views introduced by the "facade" module.
To fix this, we create an uninstall_hook which forces the removal of
the ir.ui.menus that the "facade" modules introduce, so that the
functionality remains (for modules that depend on it) but it's not
user-accessible (because it should only be accessible to users if the
facade module is installed).
The issue adressed by this fix was observed by a problem with a missing
onchange. The situation only happens when we have a one2many in a form
view with an onchange in a field in the list view, and the arch of the
list view is not inline. In that case, the onchange was not properly
triggered.
There are two causes for this bug:
- the BasicModel does not exactly receive the same data when loading a
record in a one2many with a non inline view. More specifically, there
is a confusion with the fields/viewFields in that case. This is done
because the postprocessing of the fields is slightly different when a
sub view is not inline (not ideal situation, we should fix it btw)
- when it construct a subrecord, the BasicModel did not use the correct
fields value, when there was a subview. More specifically, it used
the view.fields (which does not contain onchange informations) instead
of the view.viewFields (which contains processed/view specific
informations, including the onchange data.
This commit fixes the second issue, because this is clearly a bug, and
it actually fixes the problem. The first issue is actually okay,
because we already have a difference of behaviour between the main view
and sub views (in the first case, we have the fieldget information, not
in the second case, so the processing is already a little bit different
anyway)
Notes:
- This bug was discovered only because we added a test in 11.0, which
was forwardported and broke in master. The breakage occured because
of a recent refactoring in master which moved the arch processing
inside the views and out of the data manager.
- It is good that we discovered this bug, but I want to say that it really
sucks that forwardports are done, break the master/saas.11.2, then I
have to fix it in emergency, and it completely break my own
schedule...
wip
wip
When exporting to a tarfile, we first export each module's translations
to a file on the FS, then create a tarball from all of them.
With the P3 bytes/string split, translation export was defined to export
to a bytes IO object in order to work correctly with CSV (which work on
bytes IO for better cross-version compatibility). However the tgz file
export was left opening module's files in `w` mode, which in P3 means
text, which blows up as POFile expects to ultimately write to a bytes IO
object: it uses text, and a StreamReaderWriter is used to translate that
into an underlying bytes IO.
Fix by explicitly opening the files in binary mode.
Fixes#22700
A name_search on attribute line would possibly ends up with a domain like:
['|', ('attribute_id', '=', 'm'), ('value_ids', '=', 'm'),
('attribute_id', '=', 'm')]
which would just search the attribute.
This is caused by calling the default name_search. This commit forgo
the default name_search when we are in this attribute line special case.
courtesy-of: @fmdl
opw-813505
closes#22619closes#22760
Before this commit, when having a simple employee (group employee) accessing the form view
of hr.employee, there was traceback because the field is_address_home_a_company was not in the view
This is because of commit 2d777d5
which restricted this field to the group_hr_user (Officer) in Python
When the view itself is not group-restricted
The JS loads everything from the view but puts invisible=1 on sections that have a group
The field, in our case, is forbidden before that and is not loaded, whereas the domain in which it is used is loaded
After this commit, the view loads correctly, while avoiding leaks as intended
OPW 813721
The data in tests use 'datetime.today()'. This can
add second and milli seconds: if those are not zero,
a 4th day of work will be count (hence the '+1').
The test craches with "3 != 4" when the test was executed
on a 'zero second' time.
As Dr Emmett Brown would say : "Time traveling is just
too dangerous !"
Name of scripts piped to `odoo shell` were `__builtin__` (`builtins` in
python3), which is not really obvious (and awful if your script must
handle python2 and python3).
Change it to `__main__`, allowing to use to common pattern
`if __name__ == '__main__':`
Before this commit, when duplicating a task,
the pad of the original one was updated with plain text
Hence losing all the layout.
This was because, in all likelihood, Odoo's Etherpad server did not support pushing HTML
At the time of the commit, Odoo's pads can receive HTML.
We then push HTML by default, falling back to pushing text as before
if necessary
OPW 806064
Before this commit, when connected as a portal user, the user was not
able to post replies to existing replies. This is because the textarea
section was marked to be displayed for connected internal users only.
This commit removes the whole group restriction. Indeed, it makes sense
(as a fix), to show the textarea section for public users too. Indeed,
the "Reply" button is already shown to public users but does not do
anything. With this commit, clicking the "Reply" button shows the
textarea section for everybody and, if the user is not connected,
redirects to the login page when posting the message. This of course
needs usability improvements in master.
Note: the problem had originally been fixed for regular answers with
commit https://github.com/odoo/odoo/commit/b81b03c82d282dc94595a9beb94444041509ef25
Note 2: both mentioned problems were originally introduced by commit
https://github.com/odoo/odoo/commit/9069d0127c176317436b67b23ae5677dd9d53de7
Closes https://github.com/odoo/odoo/issues/22648
Alexandre Kühn