This commit hides the <a> representing the phone
number if it is unset. Before this commit, it
could display "false" instead of being invisible.
Now, the <a> element is no longer added to the DOM.
A test has been added to assert that behavior.
closesodoo/odoo#99905
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When you are POS user or manager and don't have any accounting acces
rights, yau get and access error when you try to invoice or close the
pos session because it tries to create account.move.
As the behavior in previous version let it do, we are putting the
missing sudo call to properly create an invoice and close a session.
closesodoo/odoo#99902
X-original-commit: 84347b43063fc3032da3e03b49fc57375d8324fc
Signed-off-by: Masereel Pierre <pim@odoo.com>
Before this commit the error raised/logged when rejecting the afterEvent
promise was imcomplete. This is due to the fact we're creating the
error inside the promise itself. In order to get a better stack trace,
the error is now declared outside of the promise.
Moreover, both `afterNextRender` and `afterEvent` functions were using
`console.error` before rejecting the promise. This is also a problem
since runbot will show the error printed by `console.error` instead of
the one of the test failure. In order to solve this issue, those two
`console.error` have been replaced by `console.warn`.
closesodoo/odoo#99899
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This link module corrects some behaviors when both modules are installed and used.
The loyalty programs of quotations and sales orders are properly handled by the Sale app
and its corresponding loyalty module. Even when it is settled by the Point of Sale app,
it is still properly being handled by the Sale loyalty module and it should continue as such.
The loyalty programs of Point of Sale is not considering the order lines created by a
quotation or sale order.
closesodoo/odoo#99756
Signed-off-by: Masereel Pierre <pim@odoo.com>
In this commit, we will unify the behavior of widgetProps with
fieldProps. So we will make two changes to widgetProps:
- We will add the attributes defined on the <widget>
- We will remove the props node because no legacy widgetLegacy needs
it anymore
closesodoo/odoo#99586
Related: odoo/enterprise#31069
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
This commit adds the id of the project to the task values sent to the front end in the portal.
This allows us to easily know which project the task is in from the front end and direct the user to the right documents pages.
Enterprise: odoo/enterprise#30838
Upgrade: odoo/upgrade#3749
Task-2944247
closesodoo/odoo#99151
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This commit wraps the span containing the project name in the portal task list in a div, in order to allow easily adding the "Documents" button next to it.
Enterprise: odoo/enterprise#30838
Upgrade: odoo/upgrade#3749
Task-2944247
Part-of: odoo/odoo#99151
This commit renames a 'Task' variable to 'Task_sudo' in the _prepare_tasks_values method, to make it clearer that it does have sudo rights.
Enterprise: odoo/enterprise#30838
Upgrade: odoo/upgrade#3749
Task-2944247
Part-of: odoo/odoo#99151
Currently, while designing the website (i.e we are in edit mode), the
livechat button (or chat window) is visible.
After this commit, the livechat button/window will be hidden while website
editor is enabled.
TaskID-2824363
closesodoo/odoo#89131
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Changing the name of model payment.acquirer to payment.provider
and everything that it touches. It is technically incorrect to
use the term "acquirer" for systems that only provide a service
of payment.
After this commit the model payment.acquirer and all related to
it will be renamed to payment.provider.
Task - 2842088
closesodoo/odoo#90899
Related: odoo/upgrade#3542
Related: odoo/documentation#1981
Related: odoo/enterprise#27131
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Fine tuning of 61b8c0c1a2.
All accounts and payments related methods were moved to the
`account_payment` module, so we are compelled to add the dependency.
Part-of: odoo/odoo#90899
When hovering the first row and/or first column of a table, the buttons
appear to edit it. These are removed in the callback of a mousemove
event on the editable. If we click for instance on the code view button
while still over the table, the mouse didn't move so the buttons are not
removed. Then after that moving the mouse doesn't trigger the callback
since the editable is not visible anymore. So the buttons stay.
This fixes that case by adding a listener to the table on mouseleave,
that will remove the buttons, then self-destroy.
closesodoo/odoo#99897
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
In stable, because we feared that some behaviors were relying on the
the default behavior of closestElement, we added an option to restrict
it to the editable.
This was safer from a retrocompatibility point of view but it was a
bad gamble overall because we forgot to use the parameter in new
code, thus introducing new bugs.
This commit removes the parameter and forces the closestElement util
to be restricted to the editable.
closesodoo/odoo#99896
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Unfortunately, the selectionchange event is triggered on document,
so we need to be careful not to affect the selection if it is not
in the editable.
Part-of: odoo/odoo#99896
This move will remove the need of the adjustment compute and therefore
will avoid writing on computed fields.
closesodoo/odoo#99891
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Let's assume the following scenario:
- be on a list or kanban view with sample data
- click on "Create" (-> opens the form view)
- in the form view, there's a kanban x2many field
Before this commit, the no content helper was displayed in the
form view, whereas it obviously should not.
The issue occurred since [1], as this commit has the unwanted
since effect to set the property `useSampleModel` to true on the
form view model, which is used in the x2many kanban renderer to
determine whether or not to display the no content helper.
This commit forces that property to `false` on views that
explicitely ask to ignore sample data.
[1] 2600d1f2aeclosesodoo/odoo#99889
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
In Reportalypse, custom reports use fields to refer to functions
allowing customizing different behaviors of the engine.
With this, all account.report models contain all the functions
of all the custom reports, leading to possible name clashes
if the functions aren't properly prefixed.
We can improve that a little: instead of having multiple fields,
we use but one, referring to an AbstractModel inheriting
from a new AbstractModel called account.report.custom.handler.
This AbstractModel simply contains the different functions
that can be overridden, and its subclasses are responsible to do so.
In the code, instead of calling _get_custom_report_function,
we check whether there is a custom handler for the report,
and call the right function on it.
task-2954761
closesodoo/odoo#98973
Related: odoo/documentation#2673
Related: odoo/enterprise#30777
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Steps to reproduce:
- Choose product with long name > product page > print labels
- choose Dymo from list + add extra content
When printing the label, the product name clips out of its bounding box.
This commit makes a small visual change so that the name fits.
If you need to further modify this, mind the extra content.
opw-2944988
closesodoo/odoo#99872
X-original-commit: cfd666b27d5728bea32f7b115e2870eeed0933cf
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
Before this commit
The method `getOrCreateLink` did not return the startNode when the
startNode was a link.
If the startNode is a link, we should not try to get the link from the
selection as we already have the link. Getting the link from the
selection should be a fallback.
When clicking on a link that within a `contenteditable=false`, because
the link startNode was not returned, the element from the selection was
not the link and `getOrCreateLink` created a new link.
task-2967314
closesodoo/odoo#99864
X-original-commit: c50c2b025c58408b2e90b7b25430c981d0bcdc2b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The main goal is to reduce the number of KB sent by the `get_views`
method to the web client by getting rid of things not used by the web
client.
This revision aims to only pass the `fields_get` info of fields
actually required by the web client.
Before this revision, for each view, the list of all fields
of all models implied in the view are passed.
For the main view, it's required to pass all the fields,
for the search view: The advanced search needs to know all fields
of the model to be able to let the user to do advanced filters and
groupbys on the model fields.
But, for the models of the subviews (one2many/many2many embbeded views),
this is not required. Only the fields included in the view are required.
Also, if the search view is not requested by the web client,
then it's also not required to pass all the fields of the main model.
After this revision, for each view, pass the `fields_get`
info of only the fields actually implied in the view.
For the search view, info of all fields are passed,
not only the ones implied in the view.
For instance, on the `get_views` of `account.move`,
this allows a gain of an extra 18,05KB,
reducing from 165.82 to 147.77KB.
In addition, before this revision, the whole content of `fields_get`
was stored in the cache of `_get_view_cache`, meaning per view.
If 3 views were requested on `get_views`
let's say kanban, list, form,
the same whole `fields_get` info, of all fields,
was stored 3 times in the cache.
This revision removes the content of fields_get of the cache
for `get_views`, to avoid storing multiple times the exact same
information in the cache, therefore gaining tremendous memory,
while not loosing that processing time.
The decrease of speed is only 1~3ms per call to `get_views`.
This is mainly because all the information gathered by `fields_get`
is already in the cache. For instance, it doesn't require any SQL
request (at the moment). e.g. the translations (string, help, selection)
are already cached.
closesodoo/odoo#99834
Related: odoo/enterprise#31167
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
An explicit access check when posting a message has been added at odoo/odoo@9920f20e4c
when adding notably computation of display_name as sudo. However this is not
the role of ``message_post`` to check access for such an implementation
details.
Access is anyway already granted through the various browse and record access
done during the posting process. Moreover even message access (creation or
read) is protected notably through its related record ACLs.
Portal/Public access on message_post is anyway done through dedicated routes
using tokens or hash/pid that call message_post as sudo. We can therefore
remove the explicit access check added a bit wildly in the middle of the code.
Task-2710804 (Mail: Clean MailThread API)
closesodoo/odoo#99654
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently using the ``chatter_post`` route to post a message implicitly checks
for access rights on related record. It is done manually in ``message_post``
that is called by the route. It is done because record name is accessed as
sudo and an explicit access has been added because of fear of information
leak.
However this is a bit out of scope for ``message_post`` to perform that check
at that point. As the underlying record is accessed numerous times, adding
an explicit check just adds queries.
In portal, users may have a token and/or a hash and a partner_id, in which
case they enter sudo mode if valid, and an error is raised otherwise. However
when not using a token and/or a hash and a PID access check is now done
directly in the controller helper. Moreover this allows to have the access
error directly instead of being possibly hidden by another error, which was
the case before this fix (was actually raising about missing email_from).
In this commit we add an explicit check on record access before entering
the post computation. That way access errors are directly raised.
A fix in accounting is necessary to ensure the right error is raised. Indeed
otherwise it currently raises due to non existing email_from, and should
raise due to ACL instead. Tests are now more inlined with classic flows.
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#99654
Since the button must be rendered when its text changes, the variable
that holds its text must be stored in the component state. The button
already had the right text before a bit by chance because the new name
was computed before the component was rendered. Now we make sure that
the component will be rendered when the name is recomputed. The problem
is visible if we slow down the getUserModelName function and go to a
forum.post from a forum.forum.
task-2889929
closesodoo/odoo#99599
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When hr_recruitment is installed and a user doesn't have any recruitment access, an access error is raised.
This commit fixes the access error, allowing the user to access the hr departments view when hr_recruitment is installed and the user has no hr_recruitment access.
task-2971553
closesodoo/odoo#99591
Signed-off-by: Kevin Baptiste <kba@odoo.com>
We now display only the lines that have documents linked to them.
In case, we want to display a line even if there are no doc, we
can do so by updating the list of counter to keep with
"getCountersToKeep()".
In case, there are no lines, we display a small message.
For now we always display the quotations, sale orders and invoices.
task-2947778
closesodoo/odoo#99373
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Partial revert of fba6ea5a47
If the designer group is not given automatically to all admins,
they are not able to go through the website onboarding automatically
launched after the website app installation.
Task ID - 2936569
closesodoo/odoo#98542
Related: odoo/enterprise#30626
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When the admin installs an app, he should see it directly, without having
to give himself the app rights on his user form.
Finetuning of #91909
Task ID - 2936569
Part-of: odoo/odoo#98542
This commit adds the possibility to link a stress day
to specific departments. If the employee is in a
sub-department of the department subject to a stress
day, the stress day will also apply for that employee.
taskID 2946420
closesodoo/odoo#97888
Signed-off-by: Kevin Baptiste <kba@odoo.com>
- Remove `_default_log_exceptions` of our `Cursor` class (unused except
in one test)
- Deprecated `serialized` args of `__init__` (Cursor class) and
`cursor()` (of Connection class), our cursor is always serialized.
- Remove `sql_log` attribute of Cursor class and replace it with
appropriate code to do the same stuff dynamically.
- Simplify some code
- Update some docstring
- Clean import
task-2766494
closesodoo/odoo#85078
Signed-off-by: Rémy Voet <ryv@odoo.com>
- Remove depreciated `after` method of `Cursor`
- Remove `unbuffer`/`flush_env`/`clear_env` methods
- Remove specific code for psycopg version < 2.7 (psycopg version is
always >= 2.7 in our requirements)
- Depreciated autocommit
task-2766494
Part-of: odoo/odoo#85078
Since e014cc88394fb9c8f6cff556ca73d5efafea030f, our proxy
`Cursor` object doesn't return a understandable error when we
try to use it when it is already closed
(`NoneType` or `Recursion` error).
Instead of reverting e014cc88394fb9c8f6cff556ca73d5efafea030f,
add a check in `__getitem__` raising a IterfaceError (like psycopg)
if we try to use psycopg cursor (`self._obj`)
task-2766494
Part-of: odoo/odoo#85078
Small fixup of recent commit [1].
A regular user do not have delete right on iap.account model, hence
creating an access right error. We should allow him to delete accounts
without token so they will be re-created afterwards.
[1]:https://github.com/odoo/odoo/commit/974caef934b7a116b7375f05e047aea15ea960aaclosesodoo/odoo#99877
X-original-commit: 53b05e7f7a7b562154a6523547678d46a8014aae
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Signed-off-by: Alex Thuyls (alt) <alt@odoo.com>
This commits fixes the fact that we were having a traceback when puting an image inside a div that was in the div with id #product_detail and clicking on the remove button in the editor. In reality this butotn should not have been available because the image is not in the carousel.
We now check that the image is in the
o_wsale_product_images div (which is the carousel) to display the remove button.
To remove an image outside of this carousel, simply click on the remove block button.
task_id=2973363
closesodoo/odoo#99757
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Before this commit, only a website.page could be used as a custom
homepage ('custom' meaning other than '/').
But it is a real use case and requirement for our users to be able to
select a controller as homepage.
For instance, an ecommerce would want its homepage to be the shop and
not a regular page from where you then have to navigate to the shop.
Right now, this can (almost) be achieved by doing some technical
advanced operations:
- Move the 'Shop' menu first in the menu navbar of the website
- Delete the specific '/' website.page for the website
- Delete the generic '/' website.page (no website_id)
That way, the system will redirect `/` to `/shop`, which is not ideal as
it should remain `/` in the URL.
That's because, until now, the homepage (`/` controller) serve order
was:
- Serve the website.page set as homepage (`website.homepage_id`),
happens when one did select another page as homepage through the page
properties dialog
- Serve the website.page having `/` as URL (default)
- Serve the first accessible menu if there no `/` page or other page set
as homepage, it acts as a last resort attempt to not serve a 404 and
to try serving relevant content (the first menu of a website is most
likely always better than a 404)
- Serve 404
This commit allows to introduce an URL as homepage, instead of only a
website.page. It can be done through the website settings in the
backend.
There is 2 main points to keep in mind about serving the homepage:
- make sure we don't serve a 404 as the website homepage. This is the
website entry point, serving a 404 is terrible. That's why we have
some fallback mechanism like serving the first menu.
- We need to serve / before fallbacking to the first menu, as a lot of
site just remove the 'Home' first menu since it is a duplicate of the
logo, which also redirect to the homepage. In such cases, it doesn't
mean that the user want his first menu to be the homepage. We
shouldn't rely on such a behavior, it should just be used as a last
resort.
With this commit, the homepage serve order is now:
- If homepage URL is set (empty by default), serve the website.page
matching it
- If homepage URL is set (empty by default), serve the controller
matching it
- If homepage URL is not set, serve the `/` website.page
- Serve the first accessible menu as last resort. It should be relevant
content, at least better than a 404
- Serve 404
Most DBs will just have a website.page with '/' as URL and keep the
homepage_url setting empty.
task-2969683
closesodoo/odoo#99100
Related: odoo/upgrade#3876
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit shows the user Dropship address field in the PO when subcontractor resupply is
done with dropshipping mechanism.
closesodoo/odoo#95770
Related: odoo/upgrade#3852
Signed-off-by: Tiffany Chang <tic@odoo.com>
This commit allows the user to archive/unarchive subcontracting rules by
toggling warehouse settings `Dropship Subcontractors` and `Resupply Subcontractors`.
Additionally, if there is no warehouse with a setting enabled, the corresponding global
routes are archived as well.
Part-of: odoo/odoo#95770
This commit introduces a new pick type used when dropshipping subcontractors,
specifically when the PO resupply relies on the dropship mechanism
this is done by using it for the rules of the `Dropship subcontractor on order` route
Part-of: odoo/odoo#95770
Before this commit, to access the location subcontractors, you needed to search
everytime, the one2many will provide this as well as cache the result for future use.
Taskid: 2848013
Part-of: odoo/odoo#95770
Before this commit, when content of dialog was long, content
overflow but was not scrollable, which makes bottom unreachable,
which is especially a problem when buttons are at the bottom.
This problem solves the issue by adding classname `modal` to
dialog. This classname puts proper handling of overflow of
dialog and its content.
Also remove `align-items-center` so that top doesn't overflow
in isolation from the rest of content, which made top unreachable.
Task-2973866
closesodoo/odoo#99865
X-original-commit: 9f4495aa065da5e94d6ccd007c9f26b7d755f140
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Since a field is put inside of the button, the space used by the button
is a bit overblown compared to the text inside, by adding oe_inline we
make it use less space.
closesodoo/odoo#99830
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
luvi