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>
If a client's name was too long (over 30 char) and in uppercase, certificate's
layout was broken.
A condition has been put in place for names over 20 char and uppercase names.
It is a best effort fix, but it will not fix all cases...
opw-2561078
closesodoo/odoo#71994
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit:
Currently, failure notifications are sent to the author of the message that the
failure is concerning.
However, if another user than the author is resolving the failure, he is not
receiving any notification without refresh the page, so it appears as if nothing
happened even though the failure was indeed resolved
(either message resent, or failure ignored).
After this commit:
When another user than the author update the status of the failure notification
(message resent or failure ignored). the statues of the failure notification
update instantly, no refresh needed to show the updated status.
Task-2178257
closesodoo/odoo#68860
Related: odoo/enterprise#18748
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit
------------------
Since https://github.com/odoo/odoo/commit/4b28f1162a85d03f9dbe0338b06758ad151ea6a8
It's not possible to override _process_job on ir.cron and
have the new method called by _process_jobs because
_process_jobs calls _proccess_job directly from the class
and do not user the registry anymore
After this commit
-----------------
Use the registry and get ir.cron model to call _process_job
closesodoo/odoo#72897
X-original-commit: b732ebfac934c8fa38a8eb55cfdb59833611c175
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
In 14.0 when changing the time amount on a timesheet line on a task, if the current layout is mobile, an error will pop up when trying to save the change. This is because we are trying to check a property of an item that does not exist.
With this commit, we first check that the item exists before trying to check its properties. Because of the order of evaluation of the "if" statement, this means we will never try to get the property of the undefined item.
opw-2534800
closesodoo/odoo#72896
X-original-commit: 19c18e476e7c92caf63bd3dda87aa8468405b4f7
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: pvh-odoo <SwagSamaSempai@users.noreply.github.com>
The 'class' attribute was not safely accessed using get. Since this attribute is not always
present the condition evaluation failed in some cases.
task-2276724
closesodoo/odoo#72894
X-original-commit: 58d3b670221b37c5c4c67ee53fbc545f6fb70395
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
html field allows to insert html structures that can be treated as elements of
odoo web client. This patch updates setLocalState method (part of the web
client) to check if an element is inside html field, so such elements will be
ignored
---
opw-2520403
closesodoo/odoo#72877
X-original-commit: d2733da4863bd03b0cf853355596a44e901405d2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Before this commit:
When user tries to create an event meeting room without selecting
'Max Capacity', it throws a Validation Error because 'Max Capacity'
is a required field.
After this commit:
We provide the default value for 'Max Capicity' field on event meeting
room to avoid default ORM Validation Error while saving the record.
Note: Because the 'Max Capacity' is a selection field, displayed with
radio widget, we can't make it required from the view unlike other fields.
Also, in the 'chat.room.mixin', when we create a chat room on the fly from
create method, instead of popping the ROOM_CONFIG_FIELDS, we propagate them
(same like in write method), so that the room being created respects value
selected by user (instead of taking the default one if we pop it).
Task-id : 2448435
closesodoo/odoo#72756
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Infobox to help the user with the replenishment. Allow those actions:
- See the different supplier with their lead time, price and quantity
- Be able to select a supplier and set it on the orderpoint
⁻ See the last delivery by mmonth for the product
- Last purchase date for each supplier
Technicaly it use a wizard and a fields char with JSON used by
a widget to display a static template. Also it creates directly
the wizard in backend instead of just let the view manage the new
object since we need a button on a one2many and if the records do
not have an id, it's not possilbe to use it.
closesodoo/odoo#72039
Task: 2519761
Related: odoo/upgrade#2596
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
The UX of the 4 main views (kanban, form, list, portal) of the project app has been globally improved.
In particular, different icons color/style were changed along with several strings, and the order of a few elements was revised to improve readability.
task-2508723
See odoo/enterprise#18387closesodoo/odoo#71011
Related: odoo/upgrade#2506
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Currently the JS logs are full of warnings and it doesn't really matter because they don't block CI.
This PR:
* flips JS warnings to trigger Python warnings
* improves qunit's logging (hopefully) so test failures are more readable and actionable
* fixes / removes / downgrades JS warnings occurring during runbot runs
* also other updates probably
closesodoo/odoo#71845
Related: odoo/enterprise#18949
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
A number of functions from `web.test_utils` have been deprecated at
the module root and should be called through submodules.
Fix a bunch of remaining cases. Also add a few missing `await`s on
`triggerMouseEvent` calls. Don't bother rewriting the imports in
unpacking style as for most updating the imports is unnecessary. Do so
for `field_one2many_tests.js` where we have to rewrite the imports
anyway:
* recursively import controlPanel, createView, mock.patch and
mock.unpatch
* remove the aliasing of controlPanel to cpHelpers
Can't have a searchpanel with both:
* a filter (`field[@select='multi']`) with a `@domain`
* *and* a category (`field[not(@select='multi')]`) with `@enable_counters`
That specific case will trigger a warning and the counters being
disabled. Fix them. Oddly enough the only cases seem to be in tests...
One of the qweb tests checks that in a t-set @t-value takes priority
over body contents. However this construct also triggers a warning
when invoked.
Mock out `window.console` during qweb tests, this suppresses that
warning.
This test sometimes fails locally.
Updating it to be a bit more modern also seems to make it more
reliable (also moved the delay between the drag & drop operation & the
steps checking as it seems more logical, but the reliability issues
had disappeared before that).
* Add test name when logging missing action ids, makes finding out
which test causes the issue much simpler.
* Suppress the warning emission in the one remaining test which
triggers it, as testing invalid action IDs is exactly the purpose of
the test.
Tip consumption is an RPC request. Because the test did not mock the
model or RPC, a warning would be triggered by the mock server.
* update `createTourManager` to forward parameters outside its very
own to the mock environment setup
* pass in a `data` to set up our model, including `fields` because for
some reason the default RPC mocking is quite cross when a model
doesn't have fields
Two internal warnings are features which literally are not (entirely)
implemented, the tests can't be fixed to avoid them. Also augmented
the log messages with which test triggered the log, as it's very hard
to debug the issue otherwise.
As for the qweb debug mode warning, there's no way to disable it
easily because multiple tours explicitly opt into debug mode (with
good reasons), so it's not enough to just bypass the `mode` setter in
the test setup helpers (test_main in POS and main_tests in web), there
would also need to be special workarounds in the 4 modules which set
`owl.config.mode` based on the session's debug mode.
I don't know that this warning is even useful, it defaults to `false`
so the only situation in which this would be relevant would be for a
third-party to use Owl *and* explicitly enable the debug mode *and*
forget to remove it when deploying to production *and* look at their
console.
* Without an explicit format string, moment() should be called with
ISO date(times).
* Correctly destroy all test locales (`zz` was not destroyed at all,
and `englishForTest` was double-destroyed instead of destroying
`frenchForTests`).
* Avoid creating a moment object from the value `false` in date(time)
fields.
* Disable the warning entirely in dates_tests, the contents are super
messy and weird.
Trigger a *lot* of spam while running tests
It's not great that this is now disabled:
* some cases are mistakes in the test e.g. RPC not properly setup,
they should really be fixed
* others are literally testing error responses, the logging should be
suppressed instead
Ideal scenario would probably be to upgrade this to `error` and have
an API of some sort to suppress it on a per-test basis (not unlike
`@mute_logger` on the Python side).
The error is (apparently) benign and already suppressed in some parts
of the system, however it can (apparently) trigger locally during some
tests, causing the test to fail as the error is caught and converted
to a failure by QUnit.
Sadly QUnit does not offer a proper hook for this, so it has to be
suppressed by wrapping the existing handler and only calling it for
other errors.
Emit JS warnings as Python warnings, otherwise it's a pain in the ass
to identify the t-raw messages (they get lost in the INFO spam).
Also just log exceptions when looking for specific messages instead of
re-raising them: if the pipe from chrome is full of exception reports,
the runner may blow its stack as it looks for the screenshot message:
on the first it takes a screenshot, then looks for the screenshot
message, finds an exception, takes a screenshot, looks for a
screenshot message, finds an exception, takes a screenshot, looks for
a s...
Before this commit: calendar view sidebar filter names were getting cropped
at bottom, it is because of line-height property which is set to 1.
After this commit: calendar view sidebar filter names will not be cropped
as line-height property set to 1.5.
task-2519813
closesodoo/odoo#72898
X-original-commit: 4e24df71f34f0306447f724fd5028778fdf46428
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
seen when working on opw-2508263c
forward-port of #72654closesodoo/odoo#72895
X-original-commit: 38906fb5a9c65335f15fd3d09399988616fbe18f
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Anjali