* web, website_event, website_sale, sale_quotation_builder
Instead of an ugly danger-colored badge promoting "odoo", we now use
the official odoo logo. The code is also refactored to use more
consistent and translatable sentences without duplicated code.
Note: the odoo logo is added in the repo, downloaded from our official
brand assets page (https://www.odoo.com/page/brand-assets), in its
'tiny' version. The repo already contained multiple odoo logos but they
are quite old and should be replaced in a further update. Note: the svg
version was not able to be used as it contains external margins...
Part of https://github.com/odoo/odoo/pull/34422
task-2026299
Don't show "Not Available" as Line header when there is only one
attribute line on the product.template.
closesodoo/odoo#35586
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
If we use a kanban view to select a record we want to hide those elements:
dropdown boxes, buttons, anchors, some widgets, kanban color.
When it was too much change and used the new attribute
"kanban_view_ref" to explicitly define which view to open in selection_mode.
When also had to create previously unexisting kanban for
fleet.vehicle.model to show name and brand.
Task ID : 1924779
- many2one widget in mobile will open kanban view instead of listview when
records needs to be selected
- Add support of "kanban_view_ref" on many2x fields:
For many2one fields, this specific kanban view will be opened when you click
on this field. Note that in desktop, the behavior stay unchanged:
'Search More' will open the tree view.
For many2many fields, this specific kanban view will be opened when you add
a record in mobile.
- Add support "selection_mode" in kanban views.
This boolean is set to true when you want to use a kaban view to
select a record instead of open a record.
"selection_mode" is now passed in qweb_context to allow developers
to use t-if='selection_mode' in kanban views to show or hide elements;
buttons, dropdowns, anchor tags are not necessary when selection_mode
is enabled. So those elements can be hidden based on this condition.
Useful when kanban view is opened from m2o in mobile environment.
Task ID : 1924779
* = web, website_blog, website_crm_partner_assign, website_event,
website_event_track, website_forum, website_hr_recruitment,
website_livechat, website_partner, website_profile, website_sale,
website_sale_delivery, website_slides
The published button name is a bit ambiguous, now it will clearly state
what it does with a new title : "Go to Website". The "Published",
"Unpublished" state is shown with the globe icon changing color
(green and red) and a title on the button.
Badge and Delivery don't have a website page, the button will then be
a publish/unpublish button in the backend.
task-2002435
closesodoo/odoo#34261
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
* set country VAT Label "CUIT" which is the country TAX id name in
Argentina in order to used in reports and other places in Odoo. CUIT
mean "Código Único de Identificación Tributaria",
* update address format of the country.
* Use the state name instead of the state code: The address for the
company and partner was showing the state code (defined by ISO) but
this one are not the ones know for the common use. In order to avoid
errors we use the state name instead of the state code.
* Also change the order of the city state and zip are shown in address
in order to match the address in Argentinain "way".
closesodoo/odoo#34961
Signed-off-by: Josse Colpaert <jco@openerp.com>
On `website` itself there is no `website_id` so the domain has to be read from
`self` directly.
Also oversight of forward-port 039e6bae99:
On `slide.channel` the override that was done in an earlier version is doing the
same as the generic override that was introduced later, so it can be removed.
closesodoo/odoo#35839
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Looks like the race condition dates back to the introduction of
"default" export fields but #32339 made it into a hard error (rather
than silently not load the fields): setting / selecting the default
fields waited in the exports lists to be loaded, but the exports lists
are just predefined lists of fields, that's got no relation to the
loaded or default fields, which are loaded (somewhat implicitly) by
_onChangeCompatibleInput.
As a result, if the lookup of the ir.exports was faster than fetching
the model's fields, we'd execute "select the fields from the list
view" before the exports widget knew anyting about the model's own
fields.
Because the old code iterated on the loaded fields and checked if they
were to enable it would just do nothing (as it would iterate an empty
object). Because the new code iterates on the defaults fields and
looks them up in the records map, it gets an undefined and triggers an
error.
Fix by waiting on the proper RPC call.
Reported-by: Andreas Stauder (@BT-astauder)
closesodoo/odoo#35837
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
When redirecting to record, the wrong 'form' view will sometimes be
loaded. A 'hack' has been done in crm_lead.py to redirect the user to
the relevant 'form' view based on the value of the 'type' field.
However, this solution is not clean as it does not solve all cases
(multiple crm.lead records loaded from the activity systray, reloading
the page after redirection, etc.)
Goal of this task is to solve those issues by merging crm.lead.form.lead and
crm.lead.form.opportunity form views. That way multi records actions will
always display the relevant information according to record type.
Note: Here some fields used as a twice in the form view just to stay
close to the current design. Still few things which are not possible
here for 'lead' and 'opportunity', that is
* A dynamic 'placeholder' on 'name' field.
* A 'domain' on 'partner_id' field.
* A 'widget' on 'probability' field.
Task 47118
closesodoo/odoo#32248
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In this commit useless code is removed
* method 'close_dialog' and 'edit_dialog' from crm.lead;
* actions: crm_opportunity_report_action_graph,
create_opportunity_simplified, crm_lead_action_activities,
merge_opportunity_act;
* views: view_create_opportunity_simplified
Indeed this is dead code and can be removed to clean a bit module.
Task 47118
analytic account data preparation is now a hook method
This allows to modify the creation method without unecessary updates
closesodoo/odoo#35784
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Task 2031686
* Change some labels on the dashboard
* Move the action "Take money In/Out" to a button because it was also dsplayed in bank journals and we only want it for cash journals
* Add reconciliation param on the first account config list, as well as a button to go to the form (it is an editable list)
* Add an action to duplicate accounts in batch
* Smartly detect when a cash statement can be extended instead of creating a new one, making it more obvious to the user that he may need to validate his previous statement(s)
closesodoo/odoo#35137
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
As the 'allow_company_ids' are now depending on the context and impact
the access to some data, we need to provide them to some controller
(route). Json route auto-pop the context when given (0322f77279)
into the environment. In the 'read_follower' route, the `check_access_rules`
raises when you want to access a document of another company (even if
this one is in your allowed companies), simply because their is no
'allowed_company_ids' key in the context. This context key is automatically
added when calling the `rpc` method in JS (as explain in session.js
of a5b6f31cf2).
To fix the wrong access error on followers reading, we simly have to give
an empty context when calling `_rpc` in the follower widget.
Task-1999686
closesodoo/odoo#35705
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
In Project app, we now ensure the company of a task. Indeed, since that
model can be billed, and is important in some business, we need to ensure
its link to a company. A task can live outside a project, so the company
of a task can not be related. Task company can be set by user, but must
be the same as the project (is set), as the task can be billed depending
on project properties.
Task-1999686
When confirming a SO creates a task, the task is in a project. The
company from the task should be the one from the project, as we will
(in the next commit) restrict the company of a task: it will only
allow a project to have task in the same company as its.
Task-1999686
Since the renderer does not know the view id, we moved the local
storage key computation up to the basic controller, which makes
more sense since the renderer is supposed to be inert.
The _processColumns function had to be moved in willStart however,
since it now needs the controller to respond to the trigger_up
and the controller is not present during the init of the renderer.
closesodoo/odoo#34051
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
purpose of this commit is to show dropdown inside the kanban box with proper UI
By default, bootstrap use Popper.js for dynamic positioning. so, We need to
disable this issue with display static for removing glitch.
expected behaviour:
after applied this commit, kanban dropdown position will be inside of kanban box.
closesodoo/odoo#27150
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The reverse charge was counted twice in the VAT Return Summary Report
A reverse charge tax is a group of taxes with:
- Reverse Charge TVA +5%(Purchase)
- Reverse Charge TVA -5%(Purchase)
When buying a product P with a reverse charge tax on it.
The only tax that must appear in the VAT Return Summary Report is
the Reverse Charge TVA -5%(Purchase)
opw:2041877
closesodoo/odoo#35499
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When using barcode to change the customer to a customer with a different
pricelist than the pos default, the customer pricelist was not
automatically selected.
This is a fine-tuning on 5603b778f6
opw-2047070
closesodoo/odoo#35602
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Before this commit, most new messages added to the mail manager were
handled as if recently posted from a document thread. As a result, it
was frequently setting a new item in the local storage to notify
other tabs from these new messages.
The intent of this behaviour is to notify other tabs of newly posted
messages in a document thread, without using a longpolling
notification. That means this logic should only apply on messages
that have been recently posted on a document thread.
Sometimes, this issue was breaking the local storage on Firefox.
It showed the error message "Quota Exceeded Error" whenever `setItem`
was used, even when items were removed beforehand. The capacity of
the storage was only a few Kbs on this domain, far from reaching the
maximum capacity. We think that this error comes from the concurrent
`setItem` on multiple tabs, but this is very hard to reproduce.
This commit fixes the issue by limiting the `setItem` to the tab
that really posted the message. Tests have been adapted in order to
pass only with this fix.
note: backport of 12.2 4bde721f9
opw-2031960
closes#35588
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
With some printers (ex: Epson TM-m30), the cash drawer only opens 50%
of the time if you just send the kick command.
A fix has already been made (odoo/odoo#33328). In the previous fix, we
retried up to five times to send the pulse, checking the status of the
drawer between each pulse. The problem was that, when we read the value
of the status, the pulse was not yet done and the status was not yet
updated. The pulse was then always sent five times, even if the first
pulse worked, making a lot of noise.
For some reason, if you read the status right after sending the pulse,
the drawer always opens and the loop is not needed anymore.
TaskID: 2045581
closesodoo/odoo#35368
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
- Set the rounding of Unit(s) to 1.0
- Create a PO for 1.4 Unit(s), validate => the picking contains
1.4 Unit(s)
- Validate the picking
The backorder wizard is displayed, and if no backorder is selected, a
crash occurs.
The quantity should be rounded when the picking is created. Otherwise,
inconsistencies will appears when it is rounded in subsequent processes.
opw-2046965
closesodoo/odoo#35560
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
_on_login_cooldown is documented as being disabled when
"base.login_cooldown_after" is set to 0, however the incorrect return
value meant setting this parameter to 0 would put every user on login
cooldown permanently.
Closesodoo/odoo#35544 reported by @rodrig92
closesodoo/odoo#35555
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The following rounding is incorrect:
```
>>> float_round(6.6 * 0.175, precision_digits=2)
1.15
```
Indeed, 6.6 * 0.175 = 1.155 ≈ 1.16.
In this specific case, the `epsilon` computed is not sufficient. A
precision of 53 gives:
normalized_value = 115.49999999999997
epsilon = 1.2823075934420547e-14
=> new normalized_value = 115.49999999999999
Bad luck, this is just not enough to tip the value in the right
direction.
However, a precision of 52 is sufficient:
normalized_value = 115.49999999999997
epsilon = 2.5646151868841094e-14
=> new normalized_value = 115.5
The value of 53 was chosen from the `binary64` number format precision.
In case of Python, the corresponding machine epsilon is 2^-52 [1].
Therefore, using 52 instead of 53 does make sense.
It is worth noting that the value of the machine epsilon
2^-52 = 2.2204460492503131e-16, which is still 2 orders of magnitude
below our dynamic estimation.
[1] https://en.wikipedia.org/wiki/Machine_epsilon
[2] `numpy.finfo(float).eps = 2.2204460492503131e-16`
opw-2047368
closesodoo/odoo#35521
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In the planner the url are generated by prepare_backend_url that takes
an action's xml id as argument. The id passed should have the format
'module_name_where_the_action_is.action_name'. In this case the id passed
was product.product_template_action_product but the action is defined in
stock thus the prepare_backend_url was not able to find the associate action
and return a wrong(default) url.
This commit change the action id passed with the correct module.
closesodoo/odoo#18812
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
[IMP] l10n_*: don't define accounts or tags on tax repartition line templates anymore for 0% taxes
[FIX] account: remove old function used to migrate the former tax model, incompatible with the new one
When validating a invoice, the billing user should have access (read) for all analytic
lines. A problem appears when timesheet is installed, since there is a mismatch with
ir.rule (a timesheet is an analytic line with a project set).
The rule "account.analytic.line.billing.user" already exists for this problem, but should
be extended to work in any case.
To reproduce:
- set a user as timesheet manager and billing user
- try to validate an invoice (or post an expense)
- got an access error with "account.analytic.line.timesheet.manager"
opw-2041615
closesodoo/odoo#35297
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
Select the option 'This Month' of a date filter
in the filter menu and then remove the facet created
correctly toggles the filter from the query but the
option is still shown as selected. This commit fixes
that situation.
closesodoo/odoo#35340
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
https://docs.python.org/3/library/stdtypes.html#truth
By default, an object is considered true unless
its class defines either a __bool__() method that returns False
or a __len__() method that returns zero
Since etree elements are iterator, they define a len function.
However it turns out that customerProfileId has always no children.
So bool(find(x)) is always False; the intended meaning was find(x) is None.
opw 1999427
closesodoo/odoo#34922
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
closesodoo/odoo#35246
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Immediate transfer (no reservation, auto-confirmation, etc) should be
the default mode when creating manually a picking. The rationale is that
"the user wants to quickly encode stuff" and "it's better for the
onboarding".
As the default mode was already changed back to "planned transfer" because
users complained, this time we adapted the code so that the default mode
could be changed in python.
- re-order the imports of stock_picking.py.
- made all links to the picking from the picking type go through
_get_action (it wasn't the case for ready).
- adapt the context in the xml so that they are parse-able by
literal_eval.
- remove three actions that weren't used anymore.
- the user can create an ir config "stock.no_default_immediate_tranfer"
fill it with anything to get back the planned mode.
task-2043846
closesodoo/odoo#35550
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Before this commit, the calendar popover was opened before the popover
widget was ready. This is not usually the way it is done in odoo.
closesodoo/odoo#31874
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
qsm-odoo