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>
Gives a bit more space to the job source name to prevent text from
cutting.
Task ID: 2575483
closesodoo/odoo#72425
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Carousels (carousel and quotes_carousel snippets) in pages created by the
configurator are not added through a drag'n'drop. onBuilt and _assignUniqueId
are thefore not called. We set the unique id directly in the xml to make
the carousel slides also work when these snippets are added by the configurator.
task-2518565
closesodoo/odoo#73256
X-original-commit: 36387994d0a3038c87a754d4c27a6d34b30137e3
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When deleting a SO with an event ticket, the number of attendees becomes
incorrect
To reproduce the error:
1. In Settings, enable "Tickets"
2. On website, register an attendee to event E
3. In module Events, open E
Error: The number of attendees (X) is incorrect. If the user clicks on
it, there are X-1 attendees: the one added on step 2 has been deleted
but the number is not updated
When deleting a SO or a SO line, the associated registration is deleted:
https://github.com/odoo/odoo/blob/3fd3fc5f782f1422f578ad38e3fad444130273a8/addons/event_sale/models/event.py#L197-L198
This is the problem: it won't trigger the `compute` methods.
In the case above, this method won't be called:
https://github.com/odoo/odoo/blob/72ce1b867dc81672e6a73a586542b20216388a05/addons/event/models/event.py#L176
So the number of seats won't be updated
This fix suggests deleting the registrations from the ORM in order to
trigger the `compute` methods.
Note: Writing the tests revealed another problem. When deleting the SO,
if a wizard `registration.editor` exists and is linked to the SO, the
deletion will trigger an SQL constraint. This is the reason why the
`ondelete` has been added to the field `sale_order_id`
OPW-2452760
closesodoo/odoo#73260
X-original-commit: 89ddb7533b82160f09b7815a292c209f8d39ece5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Steps to reproduce:
- Create a new pricelist;
- In the Price Computation, select "Formula" then
change it to "Based on Cost";
- Change the price computation back to "Percentage (discount);
- Create a sale and set this new pricelist.
Issue:
Price discount made on the cost of the product instead to get back
to sale price as default
Cause:
When switching `Compute Price` and != 'formula', not setting back
`Based on` (base) to `Public Price` (list_price).
Solution:
If compute_price is changed and new value != 'formula'; set
pricelist `Based on` to `Public Price`.
opw-2587295
closesodoo/odoo#73263
X-original-commit: 3f409c08723827766db4b3f40d7777f485e78230
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Scenario to reproduce the issue on runbot 12.0 Community:
- Go to Settings > Technical > Email > Digest Emails
- Select the Weekly Digest
- Click on Action > Delete
- Click on OK
- Go to Settings > Users & Companies > Users
- Click on Create
- Fill the Name and the Email Address
- Save
- Odoo Server Error - Missing Record
Some users seem to delete this record to stop receiving the digest for
everyone, including for future users. The problem is that, even if the
digest has been deleted, the config parameters are still referencing it.
This commit prevents the exception by having an empty recordset if the
digest does not exist.
closesodoo/odoo#73237
X-original-commit: 2910bd24f410e882b9745337f918a206b25925f7
Signed-off-by: Paul Morelle <madprog@users.noreply.github.com>
Steps to reproduce :
- Install 'Accounting'
- Create a quotation then send it (without confirming it)
- Click on Preview
Issue :
`Date` field is not preceded by a label.
Solution :
Display "Quotation Date:" label if quotation is not in one of this states :
`sale`, `done` or `cancel`.
opw-2585000
closesodoo/odoo#73181
X-original-commit: b35b8938c5fea82d27d29601b7d7a04bfc67eb66
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
In case you have installed sale_timesheet and try to do a bulk invoice creation you will be blocked if one order does not have invoiceable lines instead of skipping this specific order.
closesodoo/odoo#73261
X-original-commit: 3e03fe467b9fd459223113e477bc31811fbd35ed
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Wolfgang Taferner <wtaferner@users.noreply.github.com>
When the owl refactoring landed, we rewrote the pyjs evaluation system.
Then, we used the new system in the new code. In particular, the action
service uses it to evaluate the action domain.
But the previous code had a subtle behaviour in the special case of
evaluating domain: it added the context as a pydict object in itself, so
one could evaluate expression such as `context.get('a', 14)` to read the
value of a key in the context with a fallback.
With this commit, we uniformize this behaviour across all python
expression: the `context` key is now reserved, and used to access
anything in the current evaluation context.
closesodoo/odoo#73227
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
If $basepath in the tooling contained spaces, it could have dramatic
consequences on the rm -rf command.
We simply escape everything to avoid the problem.
closesodoo/odoo#73222
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In l10n_latam, creating a debit note with stock_account installed ends
up in stock account checking for a property in a dictionnary that may
not exist.
Using the get property will solves this issue by providing a value.
closesodoo/odoo#73221
Ticket: opw-2580992
Bug-fix: opw-2588504
X-original-commit: 423d2d4ec62312da96c66d000eaabeac4920f68f
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Brice Bartoletti <Levizar@users.noreply.github.com>
By default max cron threads is setted to 2.
But this value must be setted to 0 in the IoT
This parameter is added to odoo.conf of the IoT
closesodoo/odoo#73218
X-original-commit: 3d33b7f057f08cf1a51c59c9749996059a4983cb
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
This makes it possible to patch only _prepare_transaction_request in
case parameters need to be added.
closesodoo/odoo#73215
X-original-commit: 35a6c1867d8edc9b58c002a6ff6a63c35a0fc708
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
The commit 6eaa4a2ae3 introduced a new
view on model supplier info. The issue is that this new view is meant to
be used on supplier info as One2Many on stock.orderpoint and so contains
some `parent.` relation.
As no sequence has been set. This view replaced the original one in the
Purchase Configuration menu. Leading to some error as `parent.` in not
defined for standalone tree view.
This commit set a sequence on this new view to ensure it is used only on
the orderpoint form view.
closesodoo/odoo#73212
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Move candidate.unlink out of the for loop to unlink
records in batch.
Remove to_unlink_candidates.move_id from move_to_recompute as
move_line.unlink() will trigger recompute of their move's state.
---
opw-2585598
closesodoo/odoo#73160
X-original-commit: e2e51c15d082ec17743b73ad1422e4a223268be9
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
With this commit, we can simply skip performing a rpc when we know that
the id list given to read/unlink is empty.
closesodoo/odoo#73063
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Before this commit, orm service calls had no validation whatsoever,
which means that the requests would fail serverside, then display a
python traceback. This makes it harder for developers to find the cause
of the issue. Also, it is easy to perfom some really basic validation
anyway.
Before this commit, the block UI component was not visible so the interface
was not blocked when sending RPC (at least).
After this commit, the block UI works correctly
closesodoo/odoo#72727
Signed-off-by: Géry Debongnie (ged) <ged@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: share button inside project was displayed only in
readonly mode.
After this commit: share button inside project will be displayed in
edit mode as well.
task-2513815
closesodoo/odoo#70441
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
before this commit: create_text was passed in node options and due to which it
was not parsed by translate.py, pass add-label as attribute on field so that
translate.py parse it and it is translated.
after this commit: create_text will be passed as field attribute instead of
node options.
task-1923433
closesodoo/odoo#59713
Related: odoo/enterprise#19418
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Before this commit: When there are no columns in kanban and user is
creating very first column then it will display column + examples
clicking out closes quick create of column and due to which mockup
column also disappeared.
After this commit: Quick create of column will not discard if there
are no columns and user is creating very first column, clicking
outside will discard quick create of column if there is atleast one
column exist.
task-2517684
closesodoo/odoo#70220
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
When an installed module is not installable, we don't want
to check its dependencies because they may not be available.
Erroring out on such dependencies is not needed because
the module will not be loaded anyway. On the contrary, such
errors prevent starting a database which would otherwise
function normally.
Such errors occur when doing incremental migrations where
it happen that addons are installed (from the previous version)
but not migrated yet and therefore not installable.
When we migrate lower level dependencies Odoo marks
higher level addons as "to upgrade" even if they are not installable.
That is usually harmless, except when such addons have
dependencies that are themselve not available.
This PR fixes that.
closesodoo/odoo#73206
X-original-commit: a11e8a32883b0d0deaeb2497daa585eb3d3c686e
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
We are now using the sessionstorage to make the data the user enters when
he completes the configurator persistant during the whole session. Which
means that these data are not lost anymore on page refresh.
task-2518565
closesodoo/odoo#73101
X-original-commit: 74cc69f3908a3b1b5bfc76bb362690f72e514b00
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Finally we don't want to change the position of this button (PR #72138).
This commit moves it back to its initial place.
closesodoo/odoo#73103
X-original-commit: 60657db80248714a9b3b7269b70e8c8b25cdce11
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
PURPOSE
It has been reported that the page showing the exhibitors is slow because of the
partner table used behind the scene. It turns out that the page can generate many
links for the filters which can trick the crawlers to explore them all. As the
page is slow, the crawlers can put a high pressure on the server by exploring
those links.
SPECS
- Use a POST method to set the tag filters.
By using a POST method, the page will not longer generate links and the crawlers
will no longer explore them. This technique is actually more reliable than simply
defining a `rel="nofollow"` rule on the links.
LINKS
Task id: 2466072
closesodoo/odoo#68192
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Follow-up of [1]
Before this commit the map snippet had life-cycle and naming issues.
Also avoid partially reusing the color picker intended for background
images for the color filter overlay.
The height adjustment has also been removed, the standard top and
bottom padding can be adjusted to achieve a similar result.
[1]: https://github.com/odoo/odoo/pull/66766#pullrequestreview-685976812
Related to task-2464422
closesodoo/odoo#73180
X-original-commit: 8b9225ffd133332630097f29db9522abace7ba09
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit updates the res.currency data files to be compliant with
the ISO 4217 standard:
Add existing currencies missing from Odoo.
Remove currencies deprecated since at least 10 years.
Update incorrect currency names and rounding values.
task-2501384
closesodoo/odoo#69356
Related: odoo/upgrade#2400
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
According to Argentinean law 27440, Art. 5º it is mandatory to show the
CBU on the report for electronic invoices and electronic debit notes.
Before this commit, we were showing only in FCE (MiPyMEs), and here we
add it for NDE (MiPyMEs) on invoices reports.
closesodoo/odoo#73108
X-original-commit: d5f3e1ddff72ba05af3b8d20888b92799c7d532c
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
alt-odoo