The goal of this commit is to get rid of the analytic tags as they were confusing, serving tag purposes as well as distribution on analytic accounts.
Everywhere analytic tags were used as a distribution have been replaced with a new widget that will dispatch distribution on analytic accounts. If there was an analytic account field next to the tags, it has been included in the distribution.
Analytic tags that were used simply as information tags have been removed.
To fill the new widget, there are now 2 kind of rules that will help fill and prefill it.
The first are applicability: previous groups have been removed, and have by replaced by plans. Each account is required to have a plan. These plans define when they are available in the widget: a default applicability per plan and applicability lines that can specify rules following the context of the widget.
The second one are distribution models, that will replace previous default rules but follow the same principles. The accounts (and so the plans) that will be given by the distribution model can override the applicability rules from before.
closesodoo/odoo#98914
Related: odoo/upgrade#3885
Related: odoo/enterprise#30743
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: Habib (ayh) <ayh@odoo.com>
Before this commit, some values entered in the percentage field could
be changed due to a rounding error.
For example, the value 28 was replaced by 28.000000000000004
How to reproduce it:
- Go to a form view with percentage fields
- Enter the value 28 in the percentage field
Before this commit:
The value in the input was replaced by 28.000000000000004
After this commit:
The value in the input remains 28
closesodoo/odoo#100559
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Current behavior:
When updating the quantity of a MO after it has been confirmed, there
was no rounding applied on the move_raw.
Steps to reproduce:
- Create a new UoM A for units, with a ratio of 250 and a rounding
precision of 1
- Create a BoM for 250 quantity of product A, that use 1 quantity
of product B with UoM A.
- Create a MO for product A, and confirm it.
- Change the quantity to product by clicking on the quantity, enter any
value above 250 (e.g. 275)
- The quantity for product B should is not correct (should be 2)
opw-2964561
closesodoo/odoo#100523
X-original-commit: fdea8f8bbb865fb711d470053891545c8f627018
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Combining a fixed payment term line with another type produced incorrect example calculations in the PT preview and stopped the user from confirming an invoice.
This PR allows for the fixed amount to impact the rest of the PT computation correctly, including
the eventually discounted amounts and tax amounts.
closesodoo/odoo#100483
Signed-off-by: Laurent Smet <las@odoo.com>
*: bus, hr_holidays.
The `/bus/im_status` route polls the server every minute in order for
the user im_status to be up to date. This commit removes this poll
by sending the im_status on the bus when updating the current user
presence.
Moreover, before [1], the user bus presence was updated on each poll.
When the user didn't poll for 50 seconds, we assumed the user was
disconnected. Since [1], the bus presence is updated each 30 seconds
by the `im_status` service. This is too frequent: there is no need
to update the user presence so often.
In order not to overhelm the server with unnecessary requests, the update
presence interval as well as the delay to be considered disconnected
have been updated: the former from 30 to 60 seconds, the later from
55 to 65 seconds (assuming that a user that has missed an update
presence tick is disconnected).
[1]: odoo/odoo@a5623d2closesodoo/odoo#100249
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Issue: When a user create -> confirm and then set the invoice to draft, Another user even
with right access (in the case Billing right on the accounting access) cannot cancel it
Steps to reproduce the bug:
1) Login with admin user having administration rights set as ‘setting’.
2) Inside Customer Invoices Journal Electronic Data Interchange -> Electronic invoicing -> Set/Enable to ‘Factur-X (FR)’
3) Create an invoice ( Ex. INV/2022/00001) with admin user -> Confirm -> Reset to draft.
4) Login with the billing user (Accounting rights set to ‘Only billing rights’)
5) invoicing -> Open Invoice ( Ex. INV/2022/00001) -> Try Cancel invoice ( Ex. INV/2022/00001) without confirming it.
6) Access Error will be reproduced.
7) Go to Customer Invoices Journal -> Electronic Data Interchange -> Electronic Invoicing -> Uncheck ‘Factur-X (FR)’ -> Save.
8) Repeat above mentioned steps again -> No Access error came this time.
Solution: Give the right access to unlink an attachment from set to draft invoice.
opw-2925207
closesodoo/odoo#100245
X-original-commit: 8f61715e9048d7bb066d008c3993766e2c537db9
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Due to group inheritance mechanism, if we try to "downgrade" the group
on a user's form view, after saving the record, sometimes the changes
may be reset automatically. Same kind of confusing behavior appears when
groups are automatically added due to cross-apps access rights dependencies.
This is very confusing because users can not easily understand what is
happening and why.
This commit improves the behavior by providing a proper warning string
to user on the fly when the groups are changed (which can potentially
be reset upon saving). For better understanding of possible scenarios
and the warning linked with them, see the test-cases that explain
everything with visual hierarchy.
taskID-2646704
closesodoo/odoo#91641
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Ease the way people can unsubscribe from a digest by adding information
to the email enabling a user agent to present a button to the user that
automate the unsubscription.
Technical notes:
To ease the way people can unsubscribe from a digest, we have followed the
advice of rfc8058 by adding the following header to the email:
- List-Unsubscribe: https_URL_to_unsubscribe
- List-Unsubscribe-Post: List-Unsubscribe=One-Click
The https_URL_to_unsubscribe
- must work with the POST method but not the GET. The GET version is disabled
to avoid unintended unsubscription that could be triggered by an anti-spam
accessing the URLs in the headers.
- must unsubscribe the user without any additional steps (one click)
- should contain an opaque identifier hard-to-forge to identify the list and
the user (our token fulfills that goal). The goal is to avoid that someone
could unregister someone else easily.
- must fulfill other conditions like no cookie, no redirection, ...
It requires also that List-Unsubscribe and List-Unsubscribe-Post be covered by
a DKIM signature.
Task-2800499
closesodoo/odoo#86934
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The presence icon was bigger than the chat one.
Now they are better aligned with the employee's name.
closesodoo/odoo#100564
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit, the data-hotkey attribute set on button nodes
in form views was ignored. This commit re-introduces the feature,
enabling the keynav on those buttons.
closesodoo/odoo#100563
Signed-off-by: Georis François (fge) <fge@odoo.com>
Since odoo/odoo#98380, the `Set Status` can be selected in the `project.project`
kanban view, which was not previously feasible as considered as not suitable.
This commit prevents selecting that value.
task-2989015
closesodoo/odoo#100561
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Current behaviour:
In the context of a multilevel contact hierarchy, if a contact is creating an SO, only that contact and it's commercial partner (usually the first company when going up in hierarchy from that contact) can see the SO.
The other contacts that are in that hierarchy could see the number of related SO on the smart button, but once clicking on it, no SO were shown.
Expected behaviour:
Every direct or indirect parent of a contact should be able to see the SO, as shown in the smart button count.
Steps to reproduce:
- Create 3 contacts with the following hierarchy: Company -> Contact 1 -> Contact 2 (Company is the root)
- Create an SO with Contact 2 as a customer
- On each of the contacts, click on the SO smart button, all of them have 1 SO shown on the button, but only Constact 1 has none shown once clicked. (Regardless if Contact 1 is an Individual or Company)
Fix:
Simplify domain search to only take into account the children's ids.
There is no need to make a distinction between a contact that is a company or not, since all commercial_partners are also partners by default.
Affected versions:
- 14.0
- 15.0
- saas-15.2
- saas-15.3
- master
opw-2961030
closesodoo/odoo#100544
X-original-commit: c34e0200b2db3ad191ee08f91f9293404a2c3340
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Members of the Interviewer groups couldn't access the applicant records
due to missing read rights on the hr.applicant.skill model.
task-2986177
closesodoo/odoo#100400
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Added an option on Manufacturing Operation Type
This option allow auto-consumption up to the reserved
quantity of tracked components in manufacturing orders.
Task : 2950200
Enterprise PR : odoo/enterprise#30805closesodoo/odoo#98461
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Right now, users having enough access right can not delete the courses if
content(slides) are linked with them.
This commit allows to delete the course by cascade deleting the linked
content and the questions/quiz linked with content, if any. Since the
quiz will also be deleted along with the content, this commit removes
the 'ondelete' restriction on the content as well. Note that the check
was not robust enough anyway. One could easily remove the questions from
"Reporting > Quizzes" menu and then unlink the contents, so removing this
restriction should not hurt that much.
task-2928164
closesodoo/odoo#98682
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
1- install eComerce app and activate debug mode
2- go to Website > Configuration > Websites
3- on a website product page extra fields tab add an empty line and save
4- visit any product page on the website (500: internal server error)
Bug:
adding an empty field crashes the website server on the product page
Fix:
made the field required
opw-2945621
closesodoo/odoo#100541
X-original-commit: c00fd50ef59030848a7f7dbfff4c0ff90645cc26
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Since [1], a call to getView no longer returns the all models the
list of all their fields, because a lot of them aren't necessary.
However, it caused an issue in the following situation:
- have a form view with an x2many displayed as a list
- in the list, have a field or widget with fieldDependencies
(dependency on field A)
- in the arch, the x2many form view isn't inline
- in readonly mode, the user clicks on a row, which will open
the x2many form view
- since the form view isn't inline, a call to getView is done
- in the returned form view, field A isn't present.
Since [1], it crashed at this point because A wasn't part of the
known fields in the form view (but it was in the activeFields,
since they are shared between the x2many list and form).
This commit fixes the issue by adding fieldDependencies not only
in activeFields, but also in fields if not already there.
[1] 4636620004closesodoo/odoo#100495
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The implementation was a bit wrong for a couple things client side,
this PR fixes it.
closesodoo/odoo#100267
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
`l10n_in_gstin_partner_id` should be hidden on the journal form for non-Indian companies. It's probably also a good idea to hide `l10n_in_tin`in the country state form whenever the state added is not in India.
vat field on `res.company` should be renamed to GSTIN only when the company country is India.
task-2765567
closesodoo/odoo#100542
X-original-commit: 7888a3c43e01c4578b51fc200c7c1706fffbb330
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Before this commit, scrolling in emoji picker grid had
an undesirable "snapping" behaviour, which kept the 1st
visible row in place.
This was caused by the computation of view block of virtual
scroller not taking into account small offset inside a row.
For example, in the following scenario:
```
distanceFromTop = 1000
rowHeight = 150
```
The 1st visible row was 6th one (Math.floor(1000 / 150) = 6),
which is correct.
However the row was fully visible, instead of partially cut
(1000 % 150 = 100 => 66% overflow).
This commit takes this in-row offset into account, so that
scroll position can now make a row partially visible.
Task-2985857
closesodoo/odoo#100521
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The field personal_stage_type_id is dupplicated in the form view. It is once in
the status bar, once in the `Extra info` tab which is only displayed in debug mode.
This causes a traceback as this is not supported by the actual web client code.
closesodoo/odoo#100524
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
A feature allows to set the modifiers invisible, readonly, required
according to a key in the context
e.g.
```xml
<field name="date_approve" invisible="context.get('quotation_only', False)" optional="show"/>
```
Following odoo/odoo#99417,
back-end views are now cached.
These expressions are currently evaluated server-side,
before serving the view to the web client.
Hence, the modifier becomes for instance `invisible="1"` or `invisible="0"`
according to the context passed when calling `get_view`.
The key used to cache the views doesn't take into account such context keys.
Hence, when you asked for a view using for instance
`invisible="context.get('quotation_only')"`
A first time using the context `{'quotation_only': True}`
and a second time using the context `{'quotation_only': False}`,
on the second time, you received the view from the first time you
requested the view, where the modifier is evaluated as if the the
context was `{'quotation_only': True}`.
As we do not want to store a cached version of the view for each
possible key in the context, postprocess the evaluation of the
modifiers using the context after retrieving the view from the cache.
A better alternative would be to delegate this evaluation to the
web client, because it already has the information it needs,
it has the context value.
Modifiers using domains are already evaluated client-side,
it would make sense modifiers using context would too.
Nevertheless, as this bug has been introduced by odoo/odoo#99417,
and as we are close to the release, solve this server-side,
to keep a similar behavior than before.
We might re-consider the implementation of this later on.
closesodoo/odoo#100130
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This commit reinforces the highlight of the selected rating by adding
increasing its size and muting unselected ratings.
task-2918757
closesodoo/odoo#93676
Related: odoo/upgrade#3593
Related: odoo/enterprise#28419
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Purpose of this PR to improve generic usage of project app.
So, in this PR done following changes:
- In project.project form view :
- Divided settings into sections
- In project.update.search.view :
- Added author, description and status in quick search
- Added ancestor task in group by and replaced parent task with ancestor task
in search view
- In project.task search View:
- the filter for unread messages should be visible only if the current user
managing his notifications in Odoo
- Added my private task filter
- In project_task_view_graph
- Added a default project > stages group.
- In project.task form view:
- If stage is_closed added decoration-muted
- Replace/Add parent task with ancestor task' in group by and quick search
- analytic-tags set on project should be automatically applied to it's tasks
task-2844212
Part-of: odoo/odoo#93676
If you insert an odoo chart, match a filter with one of the
chart field, then delete the chart
=> the field matching is not removed and is still exported
The same goes for pivot and list matching when they are removed
closesodoo/odoo#100390
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
This commit removes the 'bg-white' and 'pt-3' classes used in
the Notebook template since commit https://github.com/odoo/odoo/commit/68f1c90a031a7c2f751d9c8eca7ff525e9f7e206.
Now that the component is used by other components, such as the
media dialog from web_editor, it is not appropriate to add such
style in the core component.
Also, removing the bg-white class has no concrete effect in form
views, so it can be removed safely.
closesodoo/odoo#100253
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, following this flow:
- Drop a text_image snippet,
- Upload images from the media dialog,
- Change the image to an icon,
- Double click on the icon to open the media dialog again,
- Click on the 'image' tab
- The previously uploaded images are not correctly sized
To fix that, the media dialog component template is changed: instead of
rendering all the tabs and hiding the inactive ones, it only renders
the active one. This way, the images are correctly sized at all time.
Since commits [1] and [2], the design used by tabs and the Notebook
component is more consistent, which allow us to replace that part of the
template by the component.
The Notebook component receives the list of pages to render, and will
generate the right subcomponents in the content part of its template.
[1]: https://github.com/odoo/odoo/commit/68f1c90a031a7c2f751d9c8eca7ff525e9f7e206
[2]: https://github.com/odoo/odoo/commit/ff0b2d441252560a076a3609d81c369f0ce42d19
Part-of: odoo/odoo#100253
This field is needed in l10n_mx_edi, as the dependency of a computed field. However, this module only depends from account_accountant, not account. The field thus needs to be moved to a more generic place.
closesodoo/odoo#100281
Related: odoo/upgrade#3804
Related: odoo/enterprise#31375
Signed-off-by: Laurent Smet <las@odoo.com>
Scenario:
Open a record that is invalid in database (a required field is
empty), and click on the pager to go to another record.
Before this commit, we prevented the user from leaving the record,
marked the field as invalid and displayed a notification. This is
a weird UX experiment, since the user changed nothing (he did not
even enter edit mode). In this situation, since the record hasn't
been modified, the user should be allowed to leave. This is how
the legacy form view behaved.
closesodoo/odoo#100442
Signed-off-by: Géry Debongnie <ged@odoo.com>
Following https://github.com/odoo/enterprise/pull/31202, it happens that the query for the contract history returns several times the same id if the employee has several contracts.
This commit fixes it by adding a DISTINCT to the SQL query so that ID returned are unique.
task-2974531
closesodoo/odoo#100027
Related: odoo/enterprise#31202
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The tour test_01_admin_widget_x2many was failing because of a missing
discussion. This discussion was in fact coming from a patch
during at install tests
This wasn't detected on runbot during merge since at_install and
post_install are executed in different builds. This was detected
during the nightly "all no auto tag" build.
Simply use a proper patch to avoid keeping the default value at the
end of the test.
closesodoo/odoo#100491
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Before [1], only string channels were allowed for polling. This
ensured no one could send a server-side channel from the frontend,
this PR restores this behavior.
[1]: odoo/odoo@a5623d2closesodoo/odoo#100309
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to repoduce:
- create a customer with a private address (first select "individual" to show the selection field)
- create a quotation (and/or invoice) and select this customer
- this customer cannot receive an email and cannot be contacted afterwards (this behavior is intended)
Issue:
- it's possible to choose this type of client
Cause:
- there is no address type filter for this field
Solution:
- add a condition in the domain of the field
opw-2909395
closesodoo/odoo#100487
X-original-commit: a24384b7ede2a132125d24681cba7056bc64ccbe
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Since [1], a call to getView no longer returns the all models the
list of all their fields, because a lot of them aren't necessary.
However, it caused an issue in the following situation:
- have a form view with an x2many displayed as a list
- in the list, have a field using the widget many2many_tags
along the color_field option
- in the arch, the x2many form view isn't inline
list must be present, without the color_field option,
and the color field must not be present,
- in readonly mode, the user clicks on a row, which will open
the x2many form view
- since the form view isn't inline, a call to getView is done
- in the returned form view, the color field isn't present,
the field using many2many_tags/color_field in the
list is present, and without the color_field option.
Since [1], it crashed at this point because A wasn't part of the
known fields in the form view (but it was in the fieldsInfo,
since they are shared between the x2many list and form).
This commit fixes the issue by adding the color field not only
in fieldsInfo, but also in fields.
[1] odoo/odoo@4636620004closesodoo/odoo#100479
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
When we were loading pricelists for POS, we were putting the
base_pricelist of an item in it. It comes from the prveious
implementation on javascript side when it was the reference to the
object that was shared.
As we have put it in python in a dictionnary and we need to serilize the
data.
We also only take the fields we need in POS
ISSUE-2968489
closesodoo/odoo#100425
X-original-commit: f15ac2b2688f68a049cdaa0580bb54f1e7784cab
Signed-off-by: Masereel Pierre <pim@odoo.com>
This commit also adds the necessary tests in oder to ensure that
`timesheet_uom_factor` is taken into account/ignored in the right widgets.
task-2974145
closesodoo/odoo#100378
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Changes made in #98380 were missing an extension on the factor
computation although already used.
This commit introduces the needed extension.
task-2974145
Part-of: odoo/odoo#100378
Oversight in odoo/odoo#100376
The web client sends `list` rather than `tree` when requesting
views.
However, once they went through `get_views`, they are converted back
to `tree`.
https://github.com/odoo/odoo/blob/master/odoo/models.py#L1653
So, here, we should check against `tree`, not `list`.
Could be seen in Lunch > Manager > Today's Order.
With the `id` field missing, an error is raised
```
Uncaught (in promise) Error: The following error occurred in onWillStart: "field is undefined"
```
closesodoo/odoo#100474
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Before this commit, when trying to create or edit a product from
add a line and open the 'Create Product' popup, the label 'Sales Price'
is not visible.
This issue happened due to this commit
https://github.com/odoo/odoo/commit/46526f629f7645eaac8ce86e81e806cfa392b8b8
Due to the above fix, in the product template, the label for the
list_price field becomes invisible. So here we replaced it with
a label of the lst_price field.
task-2983733
closesodoo/odoo#100197
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Adds a new option to display whether VAT is included/excluded next to
the price on product pages.
TaskId-2906053
closesodoo/odoo#99628
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Due to the new way of handling qweb assets, one file was missing from
the editor bundle, throwing a traceback when clicking on a product in
the product grid.
closesodoo/odoo#100477
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
