| Age | Commit message (Collapse) | Author |
|---|
|
before this commit: when there is a horizontal scroll in view say for example
kanban view where there are too many columns and user scrolls horizontally and
go to form view by clicking on any record and then come back to kanban view
horizontal scroll is not preserved and user is moved to scroll position 0
this is due to commit: https://github.com/odoo/odoo/commit/19eacf7d23c9413de4430a3422b5ed74b37ef242
after this commit: scrolling horizontally and then go to form view and come
back to previous view will preserve scroll position, we also consider case for
kanban view where there are too many columns and user click on 'Add Column'
user will be scrolled to new column element.
task-2418275
closes odoo/odoo#66218
X-original-commit: 171036aefe21799f7a791cc3cd73a7d249aa0b00
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
This commit aims at fixing a random bug on the runbot.
When loading the webclient, if there is no hash, a rpc is done to
read the default action of the user. When this rpc comes back, we
execute the given action (if any), or the first action (typically
Discuss). The navbar is displayed as soon as possible, it doesn't
wait for the first action to be executed. This means that the
user can open the user menu and click on 'My Profile' before the
first action is executed.
Before this commit, if the user clicked before the read rpc on
'res.users' returned, the default action (or the first) one, was
executed, even though the user clicked on 'My Profile' and thus
asked for a specific action. So basically, the user form view was
briefly shown, and then replaced by the default or first action.
Whereas this is a very rare usecase in practice (the timing is
really short), this sometimes made the totp tour fail. However,
even if it is unlikely, the client must be robust and correctly
react to concurrent requests.
This commit fixes the issue by executing the 'My Profile' action
in the DropPrevious. That way, if any 'doAction' is performed,
other pending operations (also done in DropPrevious) are dropped.
This commit also ensures that the "brand name" part in the navbar
(containing the name of the current app) is hidden when there is
no current app, as in the scenario described above, we land in
a webclient with no current app. Note that not being in an app was
something that was already handled, but not at startup.
closes odoo/odoo#57840
Related: odoo/enterprise#13277
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
|
|
The do-action handler added was calling directly doAction method of
action_manager which lead to an issue in enterprise as the override
taking care of closing home menu in web_enterprise/do_action was no
more called. This commit fixes that by calling the do_action method of
abstract_web_client and thus the override to be executed.
Originally detected in task-2282273
closes odoo/odoo#53836
X-original-commit: 7949baf08b7e07cb5f25f1a42b4eb12ed3a65a64
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
This error occurs for instance when your session expires and you
reload. At this point, the hash part of the url is duplicated and
an error is raised when the webclient tries to parse 'cids' part.
The hash part of the url should not be duplicated, but whatever the
url hash, the client should not crash either.
This commit prevents the hash part from being duplicated, and the
client from crashing when there are several occurrences of 'cids'.
closes odoo/odoo#52599
Task: 2267401
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
*bus,mail
This commit extracts the common basis of the env to use both in
the frontend and the backend. The public env now contains most of
the features that were previously (only) in the webclient env.
Moreover, the PublicRoot no longer uses the ServiceProviderMixin,
such that services are only deployed once, in the (public) env.
Owl components can now be defined in the website, and rely on a
properly built env. Legacy widgets still works as they access
services through the PublicRoot (via trigger_up) which redirects
those requests to the env.
|
|
When the web client is completely ready, it triggers an event "web_client_ready" on the bus
Some Mail OWL components rely on that mechanism to be mounted
i.e. DialogManager and ChatWindowManager
When eveluating the action to display at startup, the webclient mechanism
implies that we push the location hash each time a relevant data is available
e.g. menu_id etc...
Now, before this commit, since the hashchange handler is bound before that evaluation
it is actually triggered each time the JQuery bbq pushed a url state (this is in the API)
doc: http://benalman.com/code/projects/jquery-bbq/docs/files/jquery-ba-bbq-js.html#jQuery.bbq.pushState
This undercuts the initial loading promise chain to finish and the event "web_client_ready" was never triggered
preventing everything that relied on it to be mounted
After this commit, the webclient is artificially finalized, with the help of a new custom event
"webclient_started". So the event web_client_ready is triggered,
signalling to everyone it is in the dom and usable
A lot of bug persist though: the start() of webClient sometimes returns a rejected promise
It is worth noting that the hashchange mechanism is largely outdated and will change
in a more reliable way in the near future with the conversion of the webClient to OWL
the drop of JQuery BBQ and the direct reliance on window.history.pushState
doc: https://developer.mozilla.org/en-US/docs/Web/API/History/pushState#:~:text=The%20state%20object%20is%20a,the%20history%20entry's%20state%20object.
and on the window's "popstate" event
doc: https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event
This commit must be applied on the enterprise webclient too
closes odoo/odoo#52892
Related: odoo/enterprise#11114
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
*odoo_referral,portal
Currently, it is not possible to have one line notification,
when you are not passing the title parameter as an option when
generating the notification,then it will display the blank div
with the default button icon only. so it is not possible to have
one-line notifications since the title is mandatory.
So the purpose of the task is to make the title optional, allowing
for more minimalistic notification.
Also removed some unnecessary titles from the notification and
some stying change.
This commit also increase the autoclose delay of non sticky
notifications, from 2.5s to 4s.
task : 2264749
closes odoo/odoo#52229
Related: odoo/enterprise#10981
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Dhruv Patel <dhp@odoo.com>
|
|
*: website
The keyboard navigation mixin was initially only used in the web-client,
because of this, some of the logic for hiding the overlay was put inside
of the web-client. We recently made keyboard navigation available on
website [1]. The handlers that would hide the overlay when alt-tabbing
or clicking on the page were not registered. This commit fixes that by
making the keyboard navigation mixin register the overlay-hiding
handlers itself.
[1]: https://github.com/odoo/odoo/commit/0b0690a3934cedcab0d5e34373e8d40c2ab25660
closes odoo/odoo#50122
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
Some web actions/controllers/viewsl have been adapted to properly instantiate the
newly refactored control panel and update it accordingly. We needed to adapt the
starting mechanism of actions and controllers to ensure that the control panel
instantiation did not delay the loading of any widget.
Part of task 2196029
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
|
|
Since 671a5471cd891, services are deployed twice in the backend:
once by the webclient (as it is a ServiceProvider), and once by the
env (which now deploys the services to make them directly available
for each Owl component of the component tree). As a consequence,
some services perform twice some operations (e.g. the mail service
fetches twice the /mail/init_messaging route, the crash manager
service displays twice the tracebacks...).
This commit fixes the issue by making the webclient directly use
services from the env, instead of deploying them a second time.
Part of 2183810
closes odoo/odoo#44301
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
|
|
During the fix of the click_all test in community in 0f2a500f0e74f7e60d806217296752ee69791d4d,
I have overlooked that enterprise used this code and removed a bit too much.
Restore the start flag in enterprise.
closes odoo/odoo#41784
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Before this commit, after the introduction of OWL, for some reason,
maybe because the session is ready earlier or later, the webclient is
opening the first app sightly earlier than before, making it too early.
The click_all failed actually because, in the initialization of the
webclient, it does a read on read user, protected by a drop_previous
it tries to start the first applictaion, when this happens, the hash
changes
==> because the hash changes, it tries to open an application, with is
also protected by the same drop previous, this discarding the result of
the read and preventing the then callbacks of the read to happen.
After this commit, we are declaring that the client is ready after the
actual load of an application.
closes odoo/odoo#41695
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Go on a kanban view with a scroll bar
scroll all the way down
Open a record in form view
Use the breadcrumb to go back to the kanban
Before this commit, the kanban was re-opened
but the position were we were before opening the record was lost
This was due to 40dd121938552d3f88289d2e5fcd1d57a0dd01bb
which refactors the dom, puting the action manager on top of controllers
After this commit, when re-opening the kanban, we end up at the same position
we left it at
OPW 2074077
closes odoo/odoo#39120
X-original-commit: c0d48878c452b256859f067186567c126d8de27e
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
|
|
* = base, web, sale, stock, sale_stock, stock_account
Warnings for the onchange now takes a type to know if it needs to be
displayed with a notification. Else it is displayed with a dialog
notification (like before).
Related to https://github.com/odoo/odoo/pull/32132 and
https://github.com/odoo/odoo/pull/35209
Part of https://github.com/odoo/odoo/pull/35342
task-2047628
closes odoo/odoo#35342
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
* = test_website, partner_autocomplete
- All the rpc warnings are now displayed using the notification system
of https://github.com/odoo/odoo/commit/b94395b50175925fc7d1bd3655e5facb78a8ba2b
- test_website is up to date
Part of https://github.com/odoo/odoo/pull/32132
task-1894820
|
|
* = account, iap, point_of_sale
Removing the CrashManager templates from base.xml and moving
it to a new file (crash_manager.xml) to allow lazy loading the required
xml only when a crash occurs (necessary for the frontend as no xml is
pre-loaded).
All rpc errors/warnings are now displayed using the same modal system as
the backend (crash_manager.js).
CrashManager will now return the WarningDialog and ErrorDialog
in addition to the CrashManager itself.
In some cases an instance of CrashManager was created just to
display a warning/error dialog.
In the backend all rpc errors but sessionExpired will be logged.
If the exception is a warning, NotFound (403) or except_orm, it will be
a warning log. The rest will be exception log.
In the frontend all rpc errors will be logged using console.debug
instead of console.warn and console.error. This way we can trigger
rpc errors in tests without failing them. If a real error happend
during a test it will fall back on the backend logger to fail the test.
Part of https://github.com/odoo/odoo/pull/32132
task-1894820
|
|
Moving the rpc_error binding into the crash manager is mandatory for it
to be used in the website.
Part of https://github.com/odoo/odoo/pull/32132
task-1894820
|
|
|
|
|
|
|
|
|
|
Following f4fbaf1efae11e8bd3b1a2938ab765d391764a1b
which changes the label/checkbox structure into:
```
<div class="custom-control custom-checkbox">
<input type="checkbox" class="custom-control-input" id="customCheck1">
<label class="custom-control-label" for="customCheck1">...</label>
</div>
```
So, before this commit, there may have been multiple input with the same Id.
The consequence is that, when clicking on a label, the browser would take the first Id it found
which was erroneous, because all checkboxes in Favorites menu had the same Id
In reality, the use case goes as:
- open a x2m,
- search more
- Favorites > Save current search
> click on one the two checkboxes
> The dropdown closed, without checking the box
After this commit, when clicking on the checkbox in the favorites menu
the checkbox is toggled and the dropdown stays. Also, the checkboxed have now unique ids
OPW 1974587
closes odoo/odoo#33032
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
|
|
|
|
Install discuss, change the general setting in dev mode to disable the
"Show Effect" checkbox. Change the preferences of the user to let odoo
handle notifications. Ask another user to ping you on a chatter then go
to discuss and click the "Mark as Read" button. Traceback.
The `notification_manager` agent has been replaced by another agent in
07cd24b1ec, the code has been updated to use the new agent.
opw-1986844
closes odoo/odoo#33363
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
|
|
Today, some resources that varies very infrequentely are requested on
every page load: the menus, the translations and the qweb templates
After this commit, there will be 2 improvements that will make the
loading of the webclient faster:
1. cache almost static resources forever
when loading the /web/ page, the user session will
contain the cache key to be used to fetch these resources. As the content
of the resource itself it used to compute the hash, the request can be
put in cache by the browser forever (for a year).
The up side is that in general less requests are needed to load the web client
The down side is that the load time and number of queries of /web page
has increased to include what is needed to compute the hash of translations,
menus and qweb templates
2. trigger the loading of the menus before the download (and startup) of
the JS and CSS assets:
The menus contains the definition of the action, wich is the first thing
needed to load a page in odoo. Starting the loading of the menu much
earlier means that when they are not yet in the browser cache (see point 1),
the browser does not need to wait for the entire assets to be downloaded
and parsed before starting the 'load_menu' request, but instead start it
immediately and hold onto a promise to be used instead of the rpc 'load_menu'.
Because the request is done before anything else is loaded, including
JQuery, it is made in vanilla JS.
Co-authored-by: Julien Mougenot <jum@odoo.com>
|
|
This fix an issue in the mobile app in iOS.
Safari is less permissive and a blank page was shown.
closes odoo/odoo#33498
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
|
|
|
|
Purpose
=======
Allow the user to select the allowed companies for which he wants to see records
on top of selecting his current company.
It is confusing for users to see the records from the company he is connected to
and the records of the children companies.
Instead of using the hierarchy of companies to access records across companies,
the user can now select (from his set of allowed companies) the companies for
which he wants to access records.
/!\ This means that the user will interact with records from company A when in
company B.
Example: a SO has been created and confirmed in A. When in B, I create the
invoice from it.
Specifications
==============
1/ Deprecate the parent/children hierarchy on the res.company model. The fields are
kept on the res.company model to ensure the retro-compatibility, but won't be used
accross the standard code anymore. The only functional usage for this mechanism
was to allow to see records from several companies by creating a virtual parent
company, which will be possible with the new mechanism.
2/ By default, a user will only see the records of the company he is connected
to (or records without a company). (It is still editable by the user if needed).
For that, put this information in the user context, to allow having different
configurations on different browser tabs. Instead of having domains like
['|',
('company_id', '=', False),
('company_id', 'child_of', user.company_id.id)]
you'll have something like
['|',
('company_id', '=', False),
('company_id', 'in', company_ids)]
Note that the 'company_ids' is a value that is passed in the evaluation
context on the record rule, as we already have user, or time.
company_ids is a list of the ids of all the enabled companies in the
user's context.
3/ Out of the generic improvements brought by this task, this will illustrate
issues that could exist since several versions. For example, it should not be
possible to create a scrap order for the company A with a package of the company
B, or it should not be possible to create an invoice on the company A with
payment terms from the company B. Before the version 12.0, it was easy to
encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side
effect of the fact that the SUPERUSER_ID has become an inactive user was to
make it more difficult to introduce mismatch on the records, but haven't solved
the issue, as it was still possible to do it with parent companies
configuration. Some of these issues have been fixed in this commit, but all the
business flows should be re-tested to check if an ir.rule should be introduced
(eg: a multi company rule for stock.quand.package), if the company of a record
is correctly transfered to another record created from the first record (eg:
From a SO, create an invoice and a payment, the company of the sales order
should be transfered on the invoice and the payment, even if the company of the
sales order is A and I'm logged into the company B with the company A enabled.
4/ Currently, if I click on a button on a notification email (example 'View
Task'), I face a traceback if I'm not logged into the company of the record.
Now, if you click on a button and if you have access to the record, the correct
company will be automatically set.
5/ If I display a kanban view with several records from several companies (and
an image), all the images should be displayed.
6/ Currently if you copy paste an url, this will crash if you're not in the
correct company. This won't be fixed because it's quite impossible to do it in
a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into
the correct company, re-copy/paste -> Ok.
7/ 2 property methods have been added on the environment to retrieve the company
on which the user is logged in and the companies the user enabled, on a specific
tab.
That way, when creating a record, instead of doing
default=lambda self: self.env.user.company_id
do
default=lambda self: self.env.company_id
On the other hand, to retrieve the enabled companies, do
companies = self.env.company_ids
8/ Modify the Company Switcher widget to allow to log into another company
WITHOUT writing on the res.users (and thus bringing cache invalidation issues
and so on). Also allow to enable several companies and see records from several
companies, and independantly of the other browser's tabs.
9/ When focusing on a tab, save the current company configuration on the local
storage. That way, when doing 'CTRL+T' or a middle click, the context is
propagated to the new tab.
10/ Improve the error message in case of multi company access errors. Now, when
the user is in debug mode, display the related names of the records and the name
of the user who brings the issue.
11/ Remove the context erasing when writing on a res.users
This is probably coming from the migration to new API of the base module.
The context was not propagated at this moment, which was a common mistake at
that time. When migrating the module, probably by using the 'black box' method,
as the context was not propagated, it was erased on the new version. This is
now an issue because the context (i.e. the enabled companies) was erased when
writing on a res.users, leading to tracebacks.
See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624
12/ Fix the crash manager on redirect warnings. The issue is the following
- Create an invoice on a company without a configured CoA.
- Set a partner
- On the onchange_partner_id, a redirect warning is raised to propose you
to configure a CoA
- Click on 'Go to the configuration panel'
- A generic warning says something like 'Do you want to discard your changes?'
- Click on yes, the page refreshes, but not on the redirect action.
Now, set correctly the action on the hash, and reload instead. The breadcrumb is
lost for example, but you reach the correct action at least.
13/ Introduce a res.group to enable/disable the multi company per tab
feature.
14/ To help the users to know which tab is in which company, add the
possibility to have a favicon per company. When creating a company,
the classical 'O' icon is colored by default in a random color.
15/ Remove the company switcher on the frontend. This was mainly there
to allow a user to swicth to the company linked to the website.
This behavior is now transparent to the user. If the website A is
activated, then the company set on the context is the company of the
website.
16/ Deprecated the _company_default_get method on the res.company
model. Remove the method _get_company on the res.users model.
17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval
context. You can now use those variables on domains in the views to
access directly to the activated company.ies on the current tab.
TaskID: 1960971
closes odoo/odoo#32341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
Part of task 1896658
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
|
|
|
|
When displaying a video, with the browser window at a certain size, or
resizing it (or opening developer tools) we could the following error:
"ResizeObserver loop limit exceeded"
This can be reproduced in chromium just with this JS code:
window.onerror = function(e){ console.log(e); };
document.body.innerHTML = '<div><video controls src="v.webm"/>';
The issue only happen if:
- the video server does not support HTTP range requests
- the controls are displayed on the video
- browser size is in problematic size/resized to problematic size
And the error is raised in window.onerror but not displayed in the
developer console.
With this change, we ignore these errors until fixed in chromium.
chromium bug tracker: https://crbug.com/809574
opw-1928512
closes #30239
|
|
This branch introduces a large-scale reorganization of the
component tree generated by the web client. The short version is
that now, the control panel is a child of the view controller and
no longer a sibling. Graphically (and simplified), we go from
this:
webClient
/ | \
... ... actionManager
/ \
controlPanel viewController
/ \
to this:
webClient
/ | \
... ... actionManager
|
viewController
/ | \
ControlPanelController
/ \
CPRenderer CPModel
The motivation is that this work moves the code where it should be.
Before this commit, it was kind of weird to have code in the
controllers to render buttons outside of their root node (in
renderButtons). Also, the action manager had to take care of
coordinating search view states between view transitions.
So, this work simplifies the code. It also makes it easier to
extend. We see day after day that Odoo needs to take care of more
complex UI needs, and in many cases, these needs were quite
difficult to implement (we prefer spaghettis in our plates, not in
our code). The changes in this branch should open the way to
implement these features.
For example,
- it will now be easy to add the possibility of views (for example,
the search view or a new ControlPanel view) to add custom buttons
(of type action or object) in the control panel.
- Another need will be to serialize/ restore the state of the
search view across action boundaries (needed by the dashboard).
- Another example is the possibility for views to customize easily
the presence/absence of sub menus (filters/groupbys/favorites/
time range/...)
- Another need is an easier way for views/client action to customize
their control panel.
This commit also contains a large rewrite of the search view (so it
is more inline with our architecture and easier to maintain).
Part of task 1893568
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
|
|
* requires that current user has group_system
* only visible in debug mode (?debug)
* available at login or via debug menu
* special systray color in superuser sessions
Closes #27254
|
|
|
|
|
|
|
|
|
|
CORS error was firsly fixed with 4bd8e3e2ed48 in 11.0
Then it was cherry-pick'd and improved in 10.0 with 9f1438d5f1b.
But the improvement was lost during forward port from 10.0 to 11.0.
This commit adds the lost fix.
Closes #26812
|
|
When starting the clickEverywhere test with enterprise modules
installed, it happens that Odoo web client is not yet fully loaded.
In this situation, the test does not find any app to test.
With this commit, an attribute is added to odoo to check if the web
client is fully loaded.
|
|
מזל טוב
The direction parameter will now have a real impact on the web interface and
completly switch the direction of the interface.
Add the dependency rtlcss to switch the direction with a css postprocessor.
Two different assets will be generated for ltr or rtl
/web/content/<...>/web.assets_backend.0.css
and
/web/content/<...>/rtl/web.assets_backend.0.css
to be able to differentiate it easily
Adapt the css and views to be easier to switch direction
Render graph as it is, do not move y-axis right side, as per mathematical rule
value goes left from origin are considered negative, so keep graph as it is
for right to left language
add test cases for language direction specific assets bundle
if language direction is rtl then we also store css files in assets bundle
now we store two assets bundle, one for ltr and one for rtl language direction
test two assets bundles generated, also test two assets bundle generated for en_US and ar_SY
|
|
----------------------
Summary
----------------------
The purpose of this commit is to improve the JS code of the `mail` module.
It applies the new coding guidelines and makes some changes on the design
of some modules, such as the old ChatManager module.
Here is a short summary of the changes that have been made:
1. New coding guidelines
- snake_case to camelCase
- prefix private attributes and methods with '_'
- jsdoc on most methods
- one class per module
2. Rename/Merge some classes
- 'chat manager' becomes 'mail manager' (internal) and 'mail service' (external)
- 'chat window manager' is now included in mail manager
- 'thread' widget now named 'thread widget'
3. New model abstraction for mail objects:
- modules 'mail.model.*'
- modeling:
0..1 0..1 * *
ThreadWindow <------> Thread <-------> Message
/ \
/ \
Thread With Cache Document Thread
/ | \
/ | \
Mailbox Channel Support Channel
|
|
DM
- Thread: the superclass of threads.
- ThreadWindow: the window component of a thread.
- Message: mail objects representing messages.
- Thread With Cache: threads that can be used with search view (Discuss app compatible).
- Document Thread: represents the thread part of a chatter.
- Mailbox: represents what was previously called 'static' channel, e.g. 'Inbox'.
- Channel: mail objects representing channels, including livechat.
- DM: special kind of Channel for 1:1 communication in the backend.
- Support Channel: special channel for im_support module.
This new modeling approach let us easily add features on all threads, such as the
possibility to put any thread in a small window.
----------------------
Known issues
----------------------
[Already Present in Master]
1. When the Discuss app is in the background with 'Inbox' as the selected
Thread, when clicking on a document thread preview in the messaging menu
of the systray, the rainbow man appears.
2. When a document with the chatter is in the background, when receiving an
inbox notification from this document thread, the document thread is
automatically marked as read, which removes the notification right away.
3. Sometimes, opening a DM window from the "blank" thread window does not work.
4. Reply-to feature on Inbox is not working: no message is sent in the document
thread.
5. On the first login of admin user with demo data, the inbox counter is wrong
(it displays 6, instead of 3).
Explanation after investigation:
> On page load, it fetches the correct number of Inbox messages (3),
but the server notifies of 3 needaction messages right away,
so it wrongly assumes these are new needaction messages.
> Not possible for web client to detect that these messages should not
increment the Inbox counter while keeping same API.
6. Notifications for new document thread messages only work when the user sets
'handle with Odoo' for the Notification Management in the preferences.
> due to notifications on the longpoll bus for document thread
messages that come from needaction notifications.
> requires server-side changes to send notification on the longpoll
bus to mentionned user.
[New]
7. When receiving a message on a unjoined channel, thread window flickers
('open' > 'close' > 'open')
Explanation after investigation:
> JS logic:
a) On auto-join, ask server to join the channel and get channel infos.
b) The info tells the channel is not detached, but JS code makes decision
to detach it, and tells server the channel is now detached.
c) From (a), server notifies on longpoll bus the state of channel, which is
not detached. The web client thinks that the window state of the channel
has been changed somewhere else, and the channel is now closed.
d) From (b), server notifies on longpoll bus the state of channel, which is
detached. The web client opens the thread window of this channel.
> The flicker didn't occur before refactoring because the web client was only
updating the model of channel when it receives the longpoll notification.
> Server behaviour on 1st longpoll notification is necessary for cross-tab
synchronization for channel window state.
> New design implies that model and view should be synchronized, hence the
issue now.
> Solution: remove server-side thread window synchronization and replace with
client-side synchronization.
----------------------
Hacks
----------------------
The module `im_livechat` now uses mail objects that are compatible with Message
and Window objects:
Modeling for messages:
AbstractMessage
/ \
/ \
LivechatMessage Message
- AbstractMessage: message compatible with the thread widget.
- LivechatMessage: message used by im_livechat.
- Message: message used with the mail manager.
Modeling for thread windows:
AbstractThreadWindow
/ \
/ \
LivechatWindow ThreadWindow
- AbstractThreadWindow: behaviour share between all types of thread windows.
- LivechatWindow: window used by im_livechat.
- ThreadWindow: window used with mail_manager.
The reason for these hacks are twofold:
1. Use the thread widget in the frontend and livechat external lib bundles.
2. Do not have a dependency with the mail manager in the frontend and external
lib bundles.
|
|
Before this commit, load_action and load_views were never resolved
in case of internet connection loss.
It's because the call is triggered by web.rpc direcly who uses
ajax.rpc without any response check.
Now the rpc response is checked in web.ajax.
Thereby all responses are handled whether they come from session.rpc
or rpc.query.
Plus, it was not the responsibility of the session to check the
rpc responses.
Steps to reproduce the issue:
(1) load_action:
- Go to the app switcher for the first time
- Force disconnected from the network
-> No notification appears and the user aren't notify
(2) load_views (mobile only):
- Go to Sales -> Quotation
(In this case, the first call is 'load_views' because we need to force
to load some views like kanban view)
- Force disconnected from the network
-> No notification appears and the user aren't notify
Note: It's now important to notify the user about connection loss
because a recent improvement in mobile app replaces the 'retry screen'
and lets the webclient handle connection issues by itself.
The single odoo mobile app is supposed to work with all databases
from 10.0.
|
|
|
|
|
|
Before this commit, load_action and load_views were never resolved
in case of internet connection loss.
It's because the call is triggered by web.rpc direcly who uses
ajax.rpc without any response check.
Now the rpc response is checked in web.ajax.
Thereby all responses are handled whether they come from session.rpc
or rpc.query.
Plus, it was not the responsibility of the session to check the
rpc responses.
Steps to reproduce the issue:
(1) load_action:
- Go to the app switcher for the first time
- Force disconnected from the network
-> No notification appears and the user aren't notify
(2) load_views (mobile only):
- Go to Sales -> Quotation
(In this case, the first call is 'load_views' because we need to force
to load some views like kanban view)
- Force disconnected from the network
-> No notification appears and the user aren't notify
Note: It's now important to notify the user about connection loss
because a recent improvement in mobile app replaces the 'retry screen'
and lets the webclient handle connection issues by itself.
The single odoo mobile app is supposed to work with all databases
from 10.0.
|
|
Some people prefer not to be disturbed by any flashy information. In
this commit, we add an option to do just that. When the 'show_effect'
option is set to false, then the messages that would be displayed by an
effect will be displayed in a notification.
Task #37712
Co-authored-by: Mohammed Shekha <msh@openerp.com>
|
|
this.call('web.Notification', 'notify', params)
Display a notification at the appropriate location, and returns the
reference id to the same widget. Note that this method does not wait
for the appendTo method to complete.
@param {Object} params
@param {string} params.title notification title
@param {string} params.message notification main message
@param {string} params.type 'notification' or 'warning'
@param {boolean} [params.sticky=false] if true, the notification will stay
visible until the user clicks on it.
@param {string} [params.className] className to add on the dom
@param {function} [params.onClose] callback when the user click on the x
or when the notification is auto close (no sticky)
@param {Array<Object>} params.buttons
@param {function} params.buttons[0].click callback on click
@param {Boolean} [params.buttons[0].primary] display the button as primary
@param {string} [params.buttons[0].text] button label
@param {string} [params.buttons[0].icon] font-awsome className or image src
@returns {Number} notification id
this.call('web.Notification', 'close', notificationId)
|
|
This commits aims at adding an accesskey (a shortcut) to all buttons
in odoo. This is done by either by assigning an accesskey in the view
XML or by automatically assigning a key to the buttons using the first
available (not yet assigned as a shortcut key) letter of the text of the
button, failing that we use the latin alphabetical order to find the
first unused key.
Included in this commit:
1. Using the ALT key, automatically assign
2. When the ALT key is pressed, show the assigned shortcuts
3. Assign a number to the menu items (enterprise)
4. Activate number accesskeys without using SHIFT
5. Extra logic to support the activation of the alphabetical
accesskeys without needing to add the SHIFT key in the key
combination (except for Firefox on linux)
6. Assign a fixed accesskey to the search field
Not done:
1. Executing the primary action on dialogs using SHIFT+ENTER
2. Show the input using TAB on the appswitcher screen
Things to consider:
1. Fixing more access keys on forms that share the same features
(b.e. Validate in customer invoice and vendor bills)
2. Not assigning keys to the chatter section
|
|
the only goal of this change is not to use a jquery selector on the
body of the document.
Jquery adds an ID attribute to all the nodes it selects. This in turn
triggers the attribute change debugger in chrome, and creates a lot
of noise while debuging.
|
|
This rev. improves the way the scroll position is restored when
coming back to a view (e.g. open a kanban view, scroll, click on a
record to open it in a form view, go back to kanban using the
breadcrumbs):
- generalize the scroll position handling from web_enterprise to
web to make it available in the community webclient as well
- also restore left scroll position, not only top (especially
useful for grouped Kanban views with a lot of columns)
- handle the case where the scrolling area is a sub element of
the view (e.g. the grouped Kanban view in mobile).
Task 34037
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Co-authored-by: Ankit Sathvara <asa@odoo.com>
|
