- Go to Inventory > Configuration > Settings and activate "Expiration Dates"
- Create a storable product tracked by lot with expiration date (i.e. Component A)
- Update quantity of Component A in a lot with an expired expiration date (i.e. Lot A)
- Create a consumable product (i.e. Component B)
- Create a storable product (i.e. Product X) with a BoM having Component A & B as components
- Create a MO for Product X with a quantity to produce set to 1
- Confirm MO
- Edit MO to set quantity produced to 2
- Set consumed quantity for Component A to Lot A
- Mark MO as done
- Confirm confirmation wizard about using expired Lot A for Component A
The following Validation Error is triggered:
"This lot Lot A is incompatible with this product Component B"
In order to display lot in the confirmation wizard, the ids of the expired
lots are added in the context under key "default_lot_ids".
As we have set a produced quantity higher than the original quantity, some
additional stock moves will be created for final product and it components.
As "default_lot_ids" is still in the context at that point, it will set it
for stock move lines of both components, which will generate the Validation
Error for Component B.
"default_lot_ids" should be removed from context after confirming confirmation
wizard for expired lots.
opw-2543863
closesodoo/odoo#73302
X-original-commit: e70275f0bb7357385990e2fb9997ac495fd7f452
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Adds a new feature to count overtime when using the attendance app.
Also adds an app that links the attendance and the holidays app to allow users to convert overtime hours to time off time.
Continuation of odoo/odoo#65542
Task ID: 1904850
closesodoo/odoo#69930
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Forward-port of a commit that was wrongly forward-ported with [1], half
of the diff was lost because it landed in master before the merge of
another commit which removes what was being reintroduced here...
[1]: https://github.com/odoo/odoo/commit/e7f497b027d5931b1cf57febcab5deda573b45bbclosesodoo/odoo#73287
X-original-commit: 68d7d42cce012269342e18373a30970e2c582ba3
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This module allows an employee to create leave requests or allocation
requests from their overtime.
Depending on the configuration of the leave type, the request can be
made from:
- "My Profile" for allocation which allows employee requests;
- Time Off dashboard for leave type with no allocations;
- The employee profile for the time off manager.
TaskID: 1904850
[IMP] hr_holidays{,_attendance}: leave allocation multi create
Change leave allocation create function to a multi create one.
Task ID: 1904850
This commit adds a new model `hr.attendance.overtime`.
When an employee checks out, an overtime entry will be created when:
- the option is enabled on the company;
- the employee worked more or less than the number of hours they
were supposed to work that day.
TaskID: 1904850
Steps to reproduce the bug:
- Let's consider a product P with sale price = 0€
- P is available in the POS
- Set a barcode to P, 2312345000002 (meaning price = 0€ with check digit = 2)
- Open a session in the POS and scan 2312345003003 (meaning price = 3€ with check digit = 3)
Bug:
A line was added with P but its price was 0€ instead of 3€
PS: Function _getAddProductOptions always sets price_extra to 0€
opw:2566502
closesodoo/odoo#73245
X-original-commit: ee567231a16b12031c234400a6a37bb5b7898cec
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
- Enable Margin analysis
- Have a product [TEST] in a category with
- FIFO and Automated Valuation.
- Kit BOM with 3 items (A,B,C)
- Create a SO with [TEST] and confirm.
- Modify the BOM and remove C from the kit.
- Back to the SO, cancel it.
Traceback will show, because there no more a bom_line associated with
the move
opw-2541674
closesodoo/odoo#72696
X-original-commit: 27821b728f409d7e1a69e84d0beb5ac708e6420e
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Currently, a traceback is generated on removing a groupby when line is in edit
mode in groupable list view. It happens because the facet removal and window
click both are called at the same time.
This commit fixes the issue by ignoring the window click on removing the search
facet.
TaskID-2518527
closes#70236closesodoo/odoo#73102
X-original-commit: da51bd7ef270fe5a481b937f0a3c296d0eea196c
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
Steps to reproduce the bug:
1. Activate the 2 language “’English’ , ‘Spanish (AR) / Español (AR)’ ”
2. User -> select the language ‘Spanish (AR) / Español (AR)’
3. Create a new product (Test Product).
4. Create a another product using “Duplicate” function.
5. Rename new product name(Test Product -1)
6. Translate the name ( “Spanish (AR) / Español (AR) : 111 Spanish product “ , “English: English Product” )
7. create a purchase agreement -> select product “111 Spanish product ” -> Save -> confirm -> new quotation.
8. Purchase Quotation -> Order line
Bug:
Description shows “Test Item (copia)”
opw:2582778
closesodoo/odoo#72997
X-original-commit: 947484cd9a082003bfd5b3c2e64d6033b863aa84
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Due to EU e-commerce 'One-Stop Shop' which becomes available on 1 July 2021, EU companies involved in distance sales are able to file their taxes using the new OSS process. Adopting OSS is now simplified in Odoo.
On installation of the module, all companies having a fiscal country in the EU will be processed.
For all existing domestic taxes in the company, an associated foreign tax (standard rate, reduced rate, etc) is found in the `EU_TAX_MAP`. This mapping will be created in a fiscal position that is automatically detected based on the customers' country.
All that is required from the user, is to review the tax mappings according to the products and services sold by the company.
A refresh button is also available in the odoo settings to redo/update the fiscal positions. This might be useful after adding a new tax.
Note: The tax mapping herein is not intended to cover all possible tax mappings between EU countries, but rather, the most commonly used ones. It is advised that users with special tax cases update the created Fiscal Positions according to their requirements.
Closes [Task 2579615]
closesodoo/odoo#73042
X-original-commit: 9c548c423614d1305542ebdffdbcd0da3cf09899
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Habib Ayob <h4818@users.noreply.github.com>
- Have a Promotion program [TEST] applied automatically, which apply a
fixed amount discount on order
- Have a Sale Order, apply test via 'promotion' button
- Edit [TEST], add a mandatory code to be used
- Back to SO, add the promotion again via 'coupon' button and insert the
code
Promotion will be applied again in the order
opw-2526950
closesodoo/odoo#72860
X-original-commit: 8ff2a16401d462850b111a551a5058eef441a9b5
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Currently, activity view does not support many2one_avatar_user widget due to
which clicking on image do not open chat window, with this commit, we add
support of many2one_avatar_user widget in activity_view so that user can click
on avatar image and open chat window.
task-2554466
closesodoo/odoo#71804
Related: odoo/enterprise#18803
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Go to User list
With studio add column User type
export
Traceback will occur because the special field sel_groups_*
should not be exported
opw-2565911
closesodoo/odoo#72861
X-original-commit: 196fe4c0be19310964b41da3b8a113f6d81aed6e
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
58d3b670221b3 was not correctly forward ported, it misses the `''` fallback part
of the original commit dc20ab9c02
Without this, traceback is shown.
Step to reproduce:
- Open HTML Editor (or edit a backend view)
- Add an input with no class but a value attribute (no type or type text)
closesodoo/odoo#73057
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The #for attribute of the LABEL tag should match the #id of the INPUT
tag, not it's #name.
This regression was introduced in a171694644closesodoo/odoo#73052
X-original-commit: 979c9d71aee4b1bb6c8798bdfdbf69ac8af3fa69
Signed-off-by: Romain Tartière <romain@vittoriaconseil.com>
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
New features to show suggested links as an autocomplete when creating a menu
was introduced with 9b9829416b.
But it was missing a sudo, so non-admin editor could not read module records.
task-2583737
closesodoo/odoo#73035
X-original-commit: d8206db3da541ba3f0c3e9cb63eab802e3ff096b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Before this commit, if a parent menu had child menus and all of those were not
visible (eg linked to an unpublished page), that parent menu would still be
shown.
While it is more a choice than an error, it might makes more sense to not show
it as most of the time, that parent menu has no sense itself, it just served as
a way to group submenus. Its URL can't be clicked (as it opens a dropdown)
despite the fact it is required, and is actually most of the time a random URL
typed by the user as it has no real purpose.
The parent menu is just used as a dropdown entry and shouldn't be displayed if
there is nothing in the dropdown, instead of converting it to a regular menu.
Historically, it was decided to do it that way to fulfill this usecase:
- /dogs
- /german-sheperds
- /beagles
If you were to unpublished your beagles and german sheperds pages, the menu
would auto convert to a regular menu pointing to your dogs page.
This use case now seems less prefered than the behavior to hide that menu.
task-2583737
closesodoo/odoo#73020
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Domain terms of the form `('field', 'not in', [...])` generate incorrect
queries for translated fields, example (model `res.country`, field `name`):
```
psycopg2.errors.SyntaxError: syntax error at or near "ARRAY"
LINE 1: ...M "res_country" WHERE "res_country"."name" not in ARRAY['No ...
```
The root cause is that the right part of the term is not converted to
tuple.
Observed during the upgrade request 16639
opw-2525553
closesodoo/odoo#73030
X-original-commit: 7c4db97e21f74a429e56f6cae4d4786ee74f7e22
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
A kits bom has a component but qty is 0. When sale this kits, the 0 qty
component won't be delivered, and the delivered qty of the kits will
always be 0.
To fix it, we don't find a stock.move and bypass the quantity check
since the stock.move are not generated when bom line quantities are 0.
Task-2580118
PR #72637closesodoo/odoo#72920
X-original-commit: fad7a15560c1d454be294f1a8d1ce5a57d576900
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
We have a test case 'test_my_activity_flow_employee' that checks user's
own activty for current day. However, the creation of the activities is
done with OdooBot, and 'date_deadline' is not being passed. For this
reason, the default deadline (default value = fields.Date.context_today)
is set based on the tz of OdooBot (which is Europe/Brussels) and so it
might happen that the deadline is set on the next day (when test case
is performed just before mid-night).
In such cases, when we search for today's activites for the employee
(with absolute current date in domain, which is still before midnight),
result can be misleading as we expect one activty for the employee but
none could be found (as deadlines are set for the next day).
This commit fixes the issue by using absolute current for the test case
(whlie setting 'date_dateline' and while searching records) and thus making
it more reliable.
Note: The test case was introduced with commit https://github.com/odoo/odoo/commit/6aa3dc609cb13a469492b1a39a8fd9810040f079
TaskID-2570963
closesodoo/odoo#73034
X-original-commit: 962153a062af3f611e38c0d588febfecd9755810
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
With commit odoo/odoo@83ffe8b we ensured that while creating a child contact, it
takes language from its parent by default if any, otherwise falls back to DB
lang.
The fix was done with help of `default_get` method. However after merge of
odoo/odoo#55995 `default_get` is now called through the onchange for o2m
fields. Now we don't get the default value of `parent_id` here which
re-introduced the bug.
This commit fixes the behavior by setting the language from onchange
while creating the child contact and thus (once again) making the
language from parent contact prevail on DB lang.
We also re-use default_lang coming from parent in form view, which partially
reverts odoo/odoo@83ffe8b .
TaskID-2416922
closesodoo/odoo#72960
X-original-commit: 4d9b85bd07e487e7843dc458332dede36c2889c2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
before this commit: when user is in readonly form, hovering on color picker
widget show cursor pointer due to which user has impression that it can be
edited while color picker should display default cursor in readonly form.
after this commit: in readonly form color picker widget will display default
cursor while hovering over color.
task-2326198
closesodoo/odoo#73011
X-original-commit: a7663fd5c0bf9f09dbb7fa472b1cb0ef3aa47930
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
RATIONALE
Make it easier for users to both build and see a forecast of their sales.
PURPOSE
Introduce forecasting by notably improving kanban view on crm.leads record.
It should be possible to group by date, add / remove columns dynamically
based on a given granularity (day, month, ...) and move / quick create
records.
Objective is to show the short term forecast for opportunities (crm_lead)
based on their expected closing (date_deadline) and have an overview of the
prorated revenues for each period (defaults to month).
MAIN CONTENT
[IMP] `core`, `web`: add a range for date(time) read_group
Add a way to get the date range of a group for a date(time) field in frontend.
As long as we are using Babel 2.6.0, it is not reliable to reverse-compute the
label to a range with moment.js (and will probably never be, since these are 2
different libraries)
Add a new `<field>` xml attribute `allow_group_range_value` for the kanban view
in order to enable/disable field by field the drag&drop and quickCreate
features.
[IMP] `core`: add a new dictionary format for fill_temporal
Add a dictionary format and optional keys to `fill_temporal` context key
for more flexibility with the `_read_group_fill_temporal` method from `models.py`.
Previously, we could only fill empty groups between groups containing records.
With the new format, it is possible to specify custom bounds or a minimum
amount of groups.
[IMP] `crm`: add a forecast feature (kanban, pivot, graph, list)
`fill_temporal_service.js`
The forecast will display records classified by a date/time field. A special
rule will be applied to show only the closest records (short term forecast)
`forecast_model_extension.js`
A special filter will be applied to show only future records, from the start
of the "groupBy" period containing "today"
[IMP] `crm`: implement the forecast feature for opportunities
Add a new submenu "Forecast" in "Reporting" for CRM. Forecast shows 4 views:
1. Kanban
2. Graph
3. Pivot
4. List
[MOV] `crm`: move server actions from lead views to a dedicated file
Taking advantage of the new action_opportunity_forecast for crm leads to
create a dedicated ir_actions.xml file to store all server/client actions.
[IMP] `web`: add hover description for kanban progressbar sum field
This commit adds a sum field description when hovering the quantity at the end
of a progressbar. The description is the label (translated string
representation) of the field used for the sum.
LINKS
Task ID-2243913
DOC PR odoo/documentation#1049closesodoo/odoo#69380
Related: odoo/enterprise#18547
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When sending a notification, the company used is:
- company_id of current record or if not available,
- company_id of author or if no author,
- company_id of user
This can seem unexpected if the author is the current user and the
company_id of our user is different than the current company switcher
company.
With this changeset: the company used is:
- company_id of current record or if not available,
- company_id of author if author is different than user or,
- current company in company switcher or if not,
- company_id of user
opw-2472622
closesodoo/odoo#73031
X-original-commit: 3f61d9e2dadf47d211ed078b36e9f3a416bbbff0
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Steps:
- Active Pricelist
- Create SO --> add some lines
- Change Pricelist and remove lines
Issue:
- Button to Update prices is still visible
Fix:
- Button should not be visible as there are no lines
closesodoo/odoo#73038
X-original-commit: aab38f9d52f8629eaea1a3725e4909ac5df1b067
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When a vendor is (un)archived, we should (un)archive all related products
as well to avoid displaying archived vendors and products in the search
panel of the Order lunch and Products list views.
closesodoo/odoo#73007
X-original-commit: 259d2f36cc73892ef295a6cfdc7e72340bfd9afd
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
Before this commit, clicking on "Edit ControlPanelView" in the
debug manager actually edited the "main" view (e.g. kanban), because
we used the wrong view id.
This commit also renames "Edit ControlPanelView" into "Edit
SearchView", which is more accurate w.r.t. to the view type.
closesodoo/odoo#72995
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
This commit brings back the possibility to pass invoice ids in payment
links, a feature that was lost with commit 573ed74c. If such an id is
present in the payment link URL, the transaction that is created must
have a reference starting with the name of the invoice, and must be
linked to it.
task-2494916
closesodoo/odoo#72992
X-original-commit: 6c13a361400332955cdf5ac5a14bd1970b4f66ef
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
With commit 139dd9d, the Hosted Payment Page API of Ogone was entirely
replaced by the FlexCheckout API. This new API allows customers to
tokenize a payment method for a later use without the need of making a
purchase. However, it proved itself to be less convenient for regular
purchases as it offers less payment options than the HPP, and payments
are no longer cardholder-initiated transactions but merchant-initiated
transactions which have a higher chance of triggering an authentication
check. Furthermore, the payment flow itself is more complicated than
before.
This commit brings back the Hosted Payment Page API to work in parallel
with the FlexCheckout API and the other APIs that were left untouched.
It will be exclusively used for making online payments with a new card.
The validation flow is managed by the FlexCheckout API while the
DirectLink API manages the payment by token and offline payment flows.
task-2494916
closesodoo/odoo#72991
X-original-commit: 4fa7b772c71979f61eb098ff8d005deba834527c
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Steps to reproduce:
- Install sale_timesheet with demo data
- Add a UOM 200h with the following characteristics:
- Category: Working Time
- Type: Bigger than the reference Unit of Measure
- Bigger Ratio: 25
- Create a new product with the following characteristics:
- Product Type: Service
- Service Invoicing Policy: Prepaid
- Unit of Measure: 200h
- Create a Quotation SO1 with the following characteristics:
- Customer: Deco Addict
- a SOL with product 200h and quantity 1
- Confirm the Quotation SO1
- Create a new project P1 with the following characteristics:
- Timesheets: True
- Billable: True
- Edit the project and set the customer to Deco Addict
- Create a new task T1 with the following characteristics:
- Project: P1
- Sales Order Item: SOL of SO1 with product 200h
- Timesheet in the task
Current behavior:
- When timesheeting, the quantity of Remaining Hours on SO is decreased by 200 * nb of hours in timesheet(s).
Expected behavior:
- When timesheeting, the quantity of Remaining Hours on SO is decreased by the number of hours in the timesheet(s).
This behavior was introduced in commit b0f165bbd8041b5a01fb09122da76ba14cfa3e94
closesodoo/odoo#72988
X-original-commit: d7c0821094246d84a233b4feddd3b0174f130119
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
The commit 1355c9694e
archive all mrp operations at "Work Order" setting unticking. The good
way would be to hide the operations if the setting is deactivate.
closesodoo/odoo#72985
X-original-commit: 58d42aea296ac9ff548542a3120c6e81bbd61d02
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This commit adds a sum field description when hovering the quantity at the end
of a progressbar. The description is the label (translated string
representation) of the field used for the sum.
Task-ID: 2243913
PR odoo/odoo#69380
Taking advantage of the new action_opportunity_forecast for crm leads to
create a dedicated ir_actions.xml file to store all server/client actions.
Task-ID: 2243913
PR odoo/odoo#69380
Add a new submenu "Forecast" in "Reporting" for CRM
The Forecast shows 4 views:
1. Kanban
2. Graph
3. Pivot
4. List
Objective
Shows the short term forecast for opportunities (crm_lead) based on their
expected closing (date_deadline) and have an overview of the prorated
revenues for each period (defaults to month).
Implementation
1. Kanban
- the progressbar is using the prorated_revenue
- the forecast_field is date_deadline
- the default groupby is date_deadline
2.3. Graph, Pivot
- the measure defaults to the prorated_revenue
- the row defaults to date_deadline
4. List
- shows the prorated_revenue
The special filter "Forecast" is defined to be used by the
forecastModelExtension (JS). (define the forecast_filter context key)
The forecast_field context key is defined in the action to be used by the
forecastModelExtension and the forecastService (JS).
The demo data for opportunities is updated to spread date_deadline over 4 months
Enable drag&drop and quickCreate features for the kanban view with the use of
the allow_group_range_value <field> xml attribute
Add a "Won" flag for the forecast view to better distinguish opportunities that
need to be worked on
Test tour
Task-ID: 2243913
PR odoo/odoo#69380
ENT PR odoo/enterprise#18547
* Currently located in CRM as it is its only use. After Owl-ification of Web
Client it will probably be added as a core feature.
* Objectives:
- Kanban view:
- Kanban groups on a specific date/time field should be contiguous and show
a short term vision. Empty groups should be shown
-> FillTemporalService
-> ForecastKanbanModel
-> context.forecast_field
- Add the next period (i.e. month) with one click in the kanban view
-> ForecastKanbanRenderer
-> ForecastKanbanController
-> ForecastColumnQuickCreate
- Store specific time ranges for each granularity (year, month, ...), so
that when the user switches back to one his progress will be recovered.
(reset on page refresh)
-> FillTemporalService
- Graph, Kanban, List, Pivot views:
- Filter out data from the past (previous periods), while keeping every
records from the current period even if we are in the middle of it
-> ForecastModelExtension
-> context.forecast_filter
-> context.forecast_field
* context key `forecast_field`:
- Used to set the date/time field name, on which the forecast logic should be
applied
- This key will be used by :
a js model (for a view) / ForecastModelExtension / FillTemporalService
* ForecastModelExtension and context key `forecast_filter`:
This extension will use a filter, the groupBy value, and the
context.forecast_field to apply a custom domain constraint.
This domain constraint can also be applied by default with the
FillTemporalService, but it was decided to extract it to a filter for the user
to be able to disable it, to see "old forgotten records" and update them if
necessary. In other words, this filter enables or disables the first bound of
the domain for the read group.
- Filter "Forecast":
This filter should set the context key `forecast_filter:1`, in order
to only get future records starting from the start of the period
containing "now".
example:
now: 2021-04-26
groupBy: month
=> all records starting from 2021-04-01 match the filter
- If none of the groupBy values are the forecast_field, filters the records
on the forecast_field starting from "now"
* FillTemporalService:
This service will be used to generate or recover `FillTemporalPeriod`.
Depending on the configuration, it will return an instance handling a
certain `forecast_field`, with a certain `granularity` (hour, day, week,
month, quarter, year), for a certain `modelName`. This can be used in
multiple views to always get the same object, if it concerns the same model,
the same field and the same granularity.
The generated `FillTemporalPeriod` object is used to compute the final domain
and context to be provided to the backend `read_group`.
The objective was to limit the amount of desired groups regarding a specific
time period (cycle). Here are the cycles depending on the granularity:
granularity - cycle
-------------------------------
hour - one day
day - one week
week - one week
month - one year
quarter - one year
year - one year
In order to get a minimal amount of groups after a read_group, we can provide
an integer in the configuration : `min_groups`, which will guarantee this
amount of groups, regardless of the rest of the configuration
The default maximum amount of groups returned depends on the end of the
specific cycle reached after guaranteeing `min_groups`
We can always alter the result by directly modifying the `start` and `end`
properties of the `FillTemporalPeriod`, using the dedicated methods to do so.
Configuration of the domain with the keys `force[Start|End]Bound`
- true: applies a lower|upper bound for the domain, which means that
the subsequent read_group will search for groups [from the
start|until the end] of the FillTemporalPeriod
- false: no domain constraint applied, which means that at least every
groups with records in the database will be returned
Configuration of the context with the keys `forceFilling[From|To]`
- true: set fill_temporal.fill_[from|to], which means that at least
every groups [from the start|until the end] of the
`FillTemporalPeriod` will be returned as contiguous groups
by a read_group
- false: does not set fill_temporal.fill_[from|to], which means that
read_group will only return groups from|until the first|last
one with at least one record
The `expand` method can be used to add one interval to the end of the
`FillTemporalPeriod` depending on the granularity (add one group)
* any "forecast" view :
- should define a `forecast_field` in the context
- should use the `forecast_model_extension` with the searchModel to be able to
filter "future" records correctly
- could make use of the `FillTemporalService` to maintain a consistent domain
and context when grouping by the desired date field. The domain and
context are to be applied on __load and __reload calls in the MODEL, on the
provided domain and context, to further filter the groups returned by a
read_group.
* forecast views: graph, kanban, list, pivot
* kanban
uses: forecast_model_extension, fill_temporal_service
has a custom `column_quick_create` limited to the forecast_field which
allows to add the next group (period depends on granularity)
works with the sample_server even thought the domain and the context are
modified during the __load/__reload processes.
* graph, pivot, list
use: forecast_model_extension
Task-ID: 2243913
PR odoo/odoo#69380
* Objectives:
- Allow the generation of empty date/datetime groups outside the bounds
defined by the existing data during a read_group, with the fill_temporal
context key.
{[Jan - empty]->[Feb]->[Mar - empty]->[Apr]->[May - empty]}
This will allow to get a guaranteed amount of groups regardless of the
existing data.
- Request contiguous date/datetime groups between custom bounds which do not
cover the entire domain of existence (existing data)
[Jan] {[Jul]->[Aug - empty]->[Sep]} [Dec]
If some records were "forgotten" before the desired "interesting" period, we
won't have to display "many" undesired empty groups to show them.
* Implementation:
Modify the fill_temporal context key to accept a dictionary format,
with 3 keys, to be used in _read_group_fill_temporal:
1. fill_from
2. fill_to
3. min_groups
- (1., 2.) offer a way to guarantee that at least a certain date range will
be returned as groups. They are also the bounds to fill. Any group outside
those bounds will not be removed, but there will be no empty group added. If
any of those keys is omitted, existing bounds are used, if applicable. If
fill_from and fill_to are not specified, and there is no data, no group is
returned.
edge case example:
existing dates: [Jan, Sep]
fill_from: [Apr]
fill_to: [Jul]
interval: 1 month
result: [Jan, |Apr, May, Jun, Jul|, Sep]
general usage examples:
a. We have a Forecast in a Kanban view. We are in April and we want the
forecast to cover the [Apr - Jul] period.
- domain: [(>= Apr), (<= Jul)] (limit the read_group to
the forecast)
- fill_from: Apr (current month)
- fill_to: Jul
The result would be [Apr, May, Jun, Jul]
b. We want the same Forecast [Apr - Jul], but there is a chance that some
records were forgotten in Jan, and we want to be able to reschedule
them, but we don't need the fill_temporal to take effect from Jan.
- domain: [(<= Jul)] (we removed the first bound)
- fill_from: Apr (current month)
- fill_to: Jul
The result would be [Jan, |Apr, May, Jun, Jul|]. We have the forecast
with the fill_temporal, and every month preceding the forecast as long
as there is at least one record in it (no empty month before the
forecast).
- (3.) Will be used as a way to guarantee a certain amount of returned groups
for a read_group grouped on a {date, datetime} field. This will only work
if there is at least one group to be used as reference (starting point) to
create supplementary groups if necessary.
example :
existing dates: [Mar, Apr]
min_groups: 4
interval: 1 month
result: [Mar, Apr, May, Jun]
- fill_temporal: {} will be considered as True (backend & frontend)
- The new key options are independant from each other (do not require the
others to be set in order to function properly)
Task-ID: 2243913
PR odoo/odoo#69380
1. Objective
- We are in a Kanban view, and we group by a "date/datetime" field.
- In order to "quick create" a record in a group, or to "drag & drop" a
record between 2 groups, we need a default value for this date field.
- In this case, a group represents a "range" of dates. A default value could
be the last date of this range.
- Prior to this commit, the view had only access to a display string for this
date range. We want to have access to the concrete bounds (start/end dates)
- Since some date/datetime fields have backend constraints, it would be
difficult to generate a compliant global default value. As such, the use of
the default value should be disabled by default and activated on a field by
field basis.
2. Usage
- Use the last day (for dates), or second (for datetimes) of the range to set
a default value in kanban "quick create" and "drag & drop"
- Use the end of the range of the last group from a read_group to be able to
request the next group (chronological order) in subsequent read_group calls
3. What are the changes in this commit
- read_group from the "core" "models.py", with the added __range for
date(time) fields, a dictionary for each group. The keys are the field
names and the values are a dictionary with the following keys: value:
- from: starting date(time) of the range (inclusive)
- to: ending date(time) of the range (exclusive)
- XML changes:
- with a new xml attribute on <field> tag allow_group_range_value (for the
kanban view):
- we allow (or disallow) supported non-readonly fields to be:
- draggable
- quick created
- this attribute can be used only on date(time) fields, and if not set,
the default behavior is false
- the naming is subject to contention because it relates to
different features. The relation comes from the constraint:
To perform a drag&drop or a quickCreate, we must be able to get the
value from the group containing the record.
- JS changes:
- we add "group.range" after a read_group for date fields, which is a
dictionary: {field_name: {from, to}}, for each date(time) groupby field
- since date(time) fields can use the format "date_field:granularity" when
used in a groupby, we have to properly split out the granularity to ensure
compatibility with the code previously in place (drag&drop procedures)
- update mock_server and sample_server to make use of the date range.
Adding support for datetime grouping to both mock and sample servers, for
tests and previews.
- the default value for kanban drag&drop and quickCreate features is the
last day/second of the range for date/datetime fields
4. Why can't this range be computed from the original display value with
moment.js
The Babel python library that we use for date(time) formatting (2.6.0) is kept
at the same version as the package in stable Debian Linux. This version has
some issues with displaying weeks consistently around the new year in certain
locales.
We cannot reverse compute a date(time) label with moment.js to get a range since
nothing guarantees that the range will be the same one that Babel used to
output it.
5. read_group return format discussion
Prior to this commit, the format of the value for the groupBy field was
either :
- String : used as a display value for the group.
Most notably, for date and datetime, this value cannot be used as a field
value in most cases. It would be more practical to also return the date
range along with the display value, so that Drag&Drop and QuickCreate
functionalities can be properly enabled in views
example :
"March 2021" has the range ['&', (field, '>=', 2021-03-01),
(field, '<', 2021-04-01)]
This information is lost at the end of the read_group.
- Array : used to indicate a res_id in case of a many2one field
res_id = array[0]
field_diplay_value = array[1]
Since we cannot use the array format to send the date(time)s of the period range
because it could be confused with the many2one format, this commit introduces
the use of a new `__range` key which is a dictionary with specific related
keys to be used to defer usable data to the web client.
Task-ID: 2243913
PR odoo/odoo#69380
When a custom module is in 'to upgrade' state,
and the code has a dependency that is not yet
installed, Odoo refuses to upgrade it, and
says the new dependency is unmet.
This commit fixes this by also calling button_upgrade() in this situation,
and not only for modules in 'installed' state.
This situation arises in a version migration scenario. Custom modules are
in 'to upgrade' state after migration.
If one of these custom modules has a new dependency
after migration, it refuses to upgrade.
closesodoo/odoo#72942
X-original-commit: d5ffe0159ada953985a23c29e36763599bd10ed9
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
PURPOSE
In livechat, rating emojis(happy, neutral and sad) display with percentage of
how happy visitors are with the particular channel, click on that will show all
ratings of livechat channels and stat button is visible while creation, if it
has no rating.
SPECIFICATION
Add one computed field "rating_count" for the model 'rating.parent.mixin' which
shows the total rating amount of a particular channel and based on that field
invisible the stat button when the count is 0.
Also, display only happy face emoji with the percentage of happiness on
the kanban view of livechat channel, click on that will only display ratings of
the particular channel.
Task- 2471714
closesodoo/odoo#67336
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When selling several times a product in a POS, if the volume and weight
of this product are defined, the sales report will be incorrect
To reproduce the error:
1. Create a product P:
- Product Type: Consumable
- Available in POS: True
- Weight: 1
- Volume: 1
2. Start a POS session
3. Sell 3 x P
4. Sell 1 x P
5. In Sales > Reporting > Sales, select the pivot view
6. Remove all filters and add this one:
- Product Variant: P
7. In Measures, select "Gross Weight" and "Volume"
Error: Total weight and volume are incorrect, they are equal to 8
instead of 4
For each POS order line, an SQL request computes several fields to
generate the associated sale report. Among them, here is how the volume
is computed:
https://github.com/odoo/odoo/blob/056246665f02c331ba0589618cf030482709f1da/addons/pos_sale/report/sale_report.py#L60-L63
So, let's say we are generating the sale report associated with the POS
order line of step 3. Since there are not enough constraints in the
volume calculation, the SQL request will select all POS order lines with
product P (even those associated with other orders than the one in step
3) and add up all the volumes. Therefore, the volume of the sale report
associated with the POS order line from step 3 will be `3 + 1 = 4` which
is incorrect (it should be 3). Same thing will happen with the sale
report associated with the POS order line of step 4 (its volume will be
4 instead of 1). As a result, on pivot view, the volume displayed will
be the sum of these values, i.e. `4 + 4 = 8`, which is incorrect
The nested SQL request is actually useless and the volume can be
directly computed.
The problem is the same with the weight.
OPW-2527163
closesodoo/odoo#72946
X-original-commit: e7f296ae863a2bad6ca2305e68411e2062947543
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Anh Thao Pham (pta)