This commit fixes a few remaining bugs in loyalty:
- misplaced use of ewallet and gift view for discount program types;
- wrong context when creating a gift card (got discount and coupon);
- wrong options to program type when creating a loyalty card;
- product tag was mandatory in reward eventhough a reward product is
assigned.
task-3015891
X-original-commit: 440a853b01dbcc67ad926487764682a5c68c2c8b
Part-of: odoo/odoo#129115
Only two thread actions are allowed for the embed livechat
for now: closing the chat window and folding it. Until now,
the actions were not loaded but this is dependent of the
imported files which is not ideal.
This PR makes allowed thread actions explicit in order to
ensure only the right thread actions are available.
closesodoo/odoo#129090
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Since odoo/odoo@3c62ca1eb, `display_name` is not stored anymore; we
should use the `complete_name` field instead, that serve the same
purpose (and is not context-dependant).
closesodoo/odoo#128891
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
_*: hr_timesheet,sale_project,sale_timesheet
Generally, you don't want subtasks to be displayed at the same level
as their parent tasks. You want to consider the subtasks as part of
their parent's project, but don't want to see them directly in this
project. Rather, you want them to be accessible only via their parent.
(There are exceptions to that and we want to stay flexible.)
First solution that comes to mind is to have `project_id` set to False
for the latter tasks, but then how to get the value of the fields that
are related to the project?
So, second solution would be to have a field `project_root_id`,
which would be the project of the parent, or the grand-parent, etc.
The issue now is that we have to fields "project", and it isn't obvious
when to use one or the other.
The most simple way to answer this need is to keep one field "project",
that will always be set for (non-private) tasks,
and create a boolean field : `display_in_project`.
But we want it to be technical (no checkbox in the view).
So, when the user unsets the project on a subtask, the view will act
as if the project was unset, but in the back-end,
we'll set `display_in_project` to False and set `project_id` back.
The fact that all tasks have a project allows us to know if action x
can be perform on this task t, dependind on t.project_id.allow_x.
task-3367246
closesodoo/odoo#128281
Related: odoo/enterprise#43996
Related: odoo/upgrade#4930
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The purpose of this commit is to change the evaluation of
date_deadline based on month for 'Quote for 12 Tables' demo data.
As calculating expected revenue for next month give different amount
from expected. This is because previously 4 weeks gives 28 days
and now 1 month will set same date of next month.
Task-3414271
closesodoo/odoo#129103
X-original-commit: c08d69a00e2ab5fa72934bddee804aa17642466d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
To comply with the requirements asked by the Belgian government for
the PoS certification, some changes had to be made to the reports.
As we have to show the turnover of the session on the session report,
we decided to show this for everyone, as this is a useful information
for every user.
closesodoo/odoo#128879
X-original-commit: fbd2116db6c5208d06877831751cd7736f8d37b7
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
The `mrp.production` method `_pre_button_mark_done` will now be public
so it can be called since the web client.
This change is done in order to know if trying to mark as done a
production will return a wizard or not, which is needed in the new MRP
Display view since there is a delay before a MO is actually marked as
done and we don't want to see the wizard poping up after this delay but
before !
The method `_set_qty_producing` public is also public now because it's
called in `_onchange_producing` but saddly, the onchanges don't happen
in the MES view, so this way we can manually call it when needed.
task-3231200
Part-of: odoo/odoo#127250
In `mrp_workorder` (enterprise), we're adding a new view to process
manufacture orders and workorders: MES.
These changes are more or less related to MES. See following for the
main changes.
== Be able to mass produce an ongoing production order ==
Currently once the mo is in progress it's not possible to use
the mass produce feature anymore. Even in basic cases where the
componenets are not tracked. It's also not possible to mark
all the productions directly as done. It's needed in the
mrp display action, so we enable it everywhere
== Manage different flows with tracking ==
Currently there is 2 different flows:
- No tracking -> All the quantities easy
- Lot -> All the quantities + display button to create lot number
- Serial with component not tracked or only one: Mass produce
- Serial that require a match between components SN/Lot and finished
product serial number -> Only display it as one unit with an automatic
backorder/
task-3231200
Part-of: odoo/odoo#127250
Co-authored-by: R1D1CUL0US <clpi@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
- Add table's leg in stock;
- Don't confirm `mrp_production_3`;
- Decrease qty to produce for `mrp_production_1` and confirm it.
task-3231200
Part-of: odoo/odoo#127250
This commit enables the JS tooling for the sign_itsme module, as well as it
removes a rule in the eslintignore file that is not valid anymore since the
static/src/js folder does not exist anymore in sign.
task-3286974
closesodoo/odoo#126296
Related: odoo/enterprise#43103
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
This commit adapts the NameAndSignature component to allow usage in the sign
module by enabling customization of behavior when "auto" and "load" buttons are
clicked. It also replaces the top buttons for fa icons for a cleaner UI and
adds autofocus to the name input field.
task-3286974
Part-of: odoo/odoo#126296
Allow sharing records between company
* accounts
* taxes
* fiscal positions
* products
* ...and some related models
These records can be read and used in children companies.
This can be used to
* have different branding for different businesses
* allow more complex security rules
* consolidate branches differently
* manage different tax reports with different tax ids in the same
country
task-3371677
closesodoo/odoo#125642
Related: odoo/enterprise#43215
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
In order to manage different branches, the usability of the company
selector is being improved
* display in a hierarchic manner
* when selecting a company, select all the available children with it
task-3371677
Part-of: odoo/odoo#125642
Allow some models to be delegated to the main company of the object.
For instance:
* Have company Parent and Child
* Child has access to all the accounts of Parent
* When creating a document in Child using an account of Parent, there
shouldn't be a consistency error.
In order to do that, a new method `_check_company_domain` has been added.
This method is used when `check_company=True` is set on the field
declaration to:
* filter relational fields in the UI [^1]
* validate relational fields when writing on them in `create` and `write`
That method should also be used in the business code for models likely
to be shared amongst company branches instead of hardcoding the domain
based on `company_id`.
The same applies on domain restriction on the field declaration: the
flag `check_company` should be prefered instead of providing the domain
explicitly based on `company_id`.
Since a lot of validation and filtering will now be done based on
`parent_of`/`child_of` of the company, some support has been added for
that special case in `filtered_domain` in order to avoid doing
additional queries.
task-3371677
[^1]: because of that change, support has been added on the python
interpreter of the client to allow concatenatng domains.
Part-of: odoo/odoo#125642
Let's assume that
* Company S is a sub company of it's parent company P
* Company S has access to all the accounts and taxes of company P
* Some taxes are archived, but used
Because of the needed access rules, there will be a `parent_of` on the
record rules of accounts and taxes.
If we consider that we should consider the context key `active_test` to
add a implicit `('active', '=', True)` clause in the domain when
evaluating `parent_of` and `child_of` clauses, an access error will be
raised instead of hiding the archived records, even when simply trying
to read an archived record.
The archive feature and the security rules should be independent; if a
security rules needs to depend on the fact that a record is archived, it
should be explicit in the domain and not rely on side effects of the
implementation of `parent_of`/`child_of`
Part-of: odoo/odoo#125642
The interraction between currency rates owned by branches can not be
defined clearly.
It would also make the currency rates tables a lot bigger.
task-3371677
Part-of: odoo/odoo#125642
Add fields and tooling to support sub companies.
The new fields are
* `parent_ids`, which consists of all the ancestors of the current
company
* `root_id`, the upmost parent, which is the company controlling the
subsidiaries
* `parent_path` is added to avoid a hit on the performances when using
the multibranch feature
Also add a mechanism to ensure some fields are shared with a root
company and all it's descendents.
All fields listed by `_get_company_root_delegated_field_names` will be
readonly and copied from the `root_id`.
task-3371677
Part-of: odoo/odoo#125642
Before this commit:
Previously, when the property field was deleted, a confirmation dialog box would
open. However, this resulted in an issue where both the property field dialog
box and the confirmation dialog box overlap.
After this commit:
With this fix, when a property field is deleted, the property field dialog box
now closes before the confirmation dialog box opens. This ensures that there is
no visual overlap between the two dialog boxes.
Task-3371734
closesodoo/odoo#129080
X-original-commit: 971826ab02e7e4134e73c498d85867a74088eaf9
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
*: test_website, website
Steps to reproduce the bug:
- Drag and drop a text-image snippet onto the page.
- Add a shape to the image of the snippet by selecting the shape from
the options.
- Click on the "replace" button in the options of the image.
- In the media dialog, navigate to the "icons" tab.
- Choose an icon.
- Inspect the HTML code of the icon in the DOM.
- Bug: The 'data-shape' attribute with a value is still present.
After this commit, when replacing media, the transfer of element
attributes specific to "shape" elements only occurs towards an image and
no longer towards other media (e.g. icons).
We also prevent adding shapes to images that don't support it (e.g. SVG
files). Before this commit, when replacing a .jpeg image that had
a shape with a SVG image, the shape was not removed.
This commit also adds tests to prevent these bugs from reappearing.
task-3420533
closesodoo/odoo#129079
X-original-commit: 023b0b3124a7181fdf486df8c830bb16edd10aa6
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Steps to reproduce:
1. Go to Accounting
2. Go to Bank -> Operations
3. Select one of the lines
4. Try to create a statement
5. Traceback
Cause of the issue:
active_ids can be None
opw-3419257
closesodoo/odoo#129078
X-original-commit: 4af42cc815a50d29ba59c1f33703760e671b296c
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Signed-off-by: Antoine Demany (ande) <ande@odoo.com>
Following #127245
It happens because `_should_bypass_reservation` has been removed in 15.0
and only exist on the `stock.move` object and not the `stock.move.line`
anymore
opw-3336131
closesodoo/odoo#129076
X-original-commit: 7e917e8713e246811531f9d7c90395242e544057
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This patch solves two issues when loading translations from CSV files.
1. If there is a CoA from a custom module that is not available the load
fails.
2. If there is an uninstalled CoA in use some of its fields may be
missing thus loading values from CSV files may fail.
Both issues were observed during upgrades.
closesodoo/odoo#129068
X-original-commit: f2b2260683a284801aa0aa55850cfecb4a0ff0e4
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Alvaro Fuentes Suarez (afu) <afu@odoo.com>
This traceback raises when user remove the' product' while creating 'Sale Order'
To produce this issue:
1) Install 'sale_stock_margin'
2) Create a new "Sale Order" in sales
3) Give values to "customer" and click "confirm" button
4) Now in "Order Lines" click "Catalog" button
5) Add any "product" and remove it.
6) Now click back to Sale Order which created above through breadcrumb
7) Now remove the 'Product'
Note:- Make sure 'product_id' is visible in "Order lines".
Error: A traceback appears: "Expected singleton: product.product()"
On "_compute_purchase_price" method, product is referenced to
"compute average price".
See:-
https://github.com/odoo/odoo/blob/ee680a9365bba0ed4c0e5e741b3e8dce94fab9bd/addons/sale_stock_margin/models/sale_order_line.py#L10-L19
Because of user removed the 'product', it return none in self which leads to
above traceback.
sentry-4320939660
closesodoo/odoo#129067
X-original-commit: a5b04bebc80c3c483bfe2eaf6c22f47613a0f0a0
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
before this commit, on clicking the purchase kanban view,
it allows to quick create from the kanban view,
and the value entered is going to name of purchase order
after this commit, quick create is disabled
closesodoo/odoo#129028
X-original-commit: 9c9433f3ebd65cfee8eceb751481116488ced3fc
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The domain was forced to fix multi-company rules, but now is missing
domain checking whether the resource.calendar.leave is of "leave" type.
This is set if the domain is None but since the domain is overridden, it
needs to be set explicitly
closesodoo/odoo#128993
X-original-commit: 4e91aed5c31114064514f5a9e9c0ab0332580208
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Kevin Baptiste <kba@odoo.com>
=== ISSUE 1 ===
The spacing between the navigation buttons in Calendar were managed
by a `gap-1` class. This worked but it was not consistent with
the navigation we have in project gantt view. In order to improve
the consistency of our UI, we need to make this look the same.
=== ISSUE 2 ===
If you navigate to Time Off and request a new time off, the datetime
picker `apply` position is not correct. This is due to the fact that
no `state.timeValues` is visible to position it accordingly. That means
we need to specify two different layout depending if these buttons are
visible or not.
== AFTER ===
We remove the `gap-1` class and add a `btn-group` class instead,
which manage the spacing between children buttons.
We also change the navigation icons to `arrows` one and fix two issues
related to the datetime picker :
- The gap between month name isn't computed as it should ;
- There is an issue with the position of the `apply` button
when no `state.timeValues` is displayed.
task-3389679
part of task-3326263
closesodoo/odoo#128460
X-original-commit: c0b354e14a18667463451aa6fe768bffcbb9da9a
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
use product tags to display information as color/image on the product
page, enable filtering by tags, add tags to specification/comparison
table. Remove the link between ribbons and tags because there is no use
as we are able to show the tags on the page, add ribbon to
product.product
task-3299538
closesodoo/odoo#124299
Related: odoo/upgrade#4824
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This PR aims to improve two sale flows in project:
## Ease SO creation from project
### Purpose
Currently, users have to create a project on one side, create an SO on the other side and then manually link the two elements together for the project to be billable. This is not the most intuitive and creates friction during the creation of a project. Indeed, the user would reach a dead-end when configuring their project employee/SOL mapping, as new SOLs cannot be created from there. As a consequence, this task aims at giving users the possibility of creating an SO directly from their project.
### Changes
- Added a "Sales Order" stat button to the project form view.
- Contains SOs linked to the SOLs set on the project, its tasks and their timesheets.
- Hidden if the project is FSM, non-billable or without a partner.
- Sales Orders created through this stat button should have at least one product of type "service".
- If the project doesn't have a Sales Order Line, creating a SO sets the first service SOL of the created SO on the project.
## Offer a view on SOLs from project updates
### Purpose
Support the use-case of lawyer firms. Indeed, they usually create one SOL per action they complete for their customer. They need an easy to create a new SOL and a way to search among all of their SOLs. We are thus adding a link to the list of SOLs from the right-side panel of project updates.
### Changes
- Added a "Sales Order Items" stat button in project update.
- Contains the SOLs linked to the project, its tasks and their timesheets.
- Hidden if the project is FSM, non-billable or without a partner.
- SOLs created through this stat button will be added to the SO of the project.
- If there is no such SO or if the current user doesn't have access to it, a new SO will be created instead.
- Refactored the SOL form view to be able to easily reuse it for this flow.
- Following this change, the ability to create SOLs on the fly from a Many2one field was added to multiple places.
- Available in helpdesk.ticket, project.project and project.task form view, as well as project employee mapping.
- The name entered in the field will be used to get a default product for the SOL, if a product with a matching name can be found.
closesodoo/odoo#121263
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Description:
Follow up on #128696, because the fw-port in 15.0 was merged before the
additional changes could've been added.
Affected versions:
15.0 -> master
opw-3302460
closesodoo/odoo#129081
X-original-commit: 6435bcb144a72ccfec3107d81b96c7eb2f4089fa
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
If applied, this commit will solve the issue of the list view selection when
the record is not actually created but it can be selected and can able to
perform the action.
Steps to produce:
- Open Accounting > Configurations > Chart of Accounts.
- Click on the 'New' button.
- Select the new line which has been added.
- Perform the 'Duplicate' action for that record.
This commit will fix the generic issue by preventing the record selection while
the record is in 'Edit' mode.
sentry - 4191036697
closesodoo/odoo#129000
X-original-commit: 5570216c8c852b5851526217858b5b7515309444
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Signed-off-by: Parth Solanki (paso) <paso@odoo.com>
This commit allows creating SOLs on the fly from various places:
- Project employee mapping list view
- Project from view
- Task form view
Task-3278895
This commit hides the "Sales Order Line" field on tasks when no customer is set on them.
It doesn't really make sense to have a SOL without a partner, and it eases other flows to be able to assume that a SOL implies that there is a partner.
Task-3278895
This commit moves the "Sales Order Line" field in the project form view from `sale_timesheet` to `sale_project`,
as the field itself is introduced in `sale_project`
Task-3278895
This commit adds a "Sales Order Line" stat button in project updates to easily search among the SOLs of a project
and be able to create new ones.
Task-3278895
This commit adds a "Sales Order" stat button in the project form view to ease the creation of a SO from a project.
This stat button is displayed if the project is billable and has a partner.
Task-3278895
* = project,timesheet
This commit changes the label when grouping tasks and timesheets by sol in the
portal for records without sol from "No Sales Order Item" to "Not Billed",
which conveys more clearly to the user that the records are not billed.
Task-3278895
Before commit:
After sending e-invoice, when requesting for edi cancellation, e-invoice is also
cancelled even if error in response.
After commit:
After sending e-invoice, when requesting for edi cancellation,
e-invoice is not cancelled in case of error in response.
closesodoo/odoo#129074
X-original-commit: 2af74c260a6223256e3a975f1378bfa25728edfb
Signed-off-by: Josse Colpaert <jco@odoo.com>
Since the introduction of project_todo, access to the model project.task
for interal users has been extended to read/write/create/unlink. The
basic record rule for task visibility does in consequence need to manage
only the read access. A new record rule was introduced to manage
write/create/unlink access for project users. However, the read access
for this group was also managed by this new rule, which led to
evaluation of both ir.rule for project user.
related-https://github.com/odoo/odoo/pull/115390closesodoo/odoo#129058
X-original-commit: 0808286feb463f7618fdc2e72f010d151db8c9a3
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Valentin Vallaeys (vava)