We here fix the `SurveyQuestionAnswer._compute_display_name`
method introduced in 55fa52be.
`survey.question.answers` used as matrix rows and columns
require different treatment as they are not used in triggers
but are both shown on the `survey.user.input.line` views,
where the display shouldn't change (nor cause a crash).
It also doesn't make much sense to create answers outside the
context of a question, so we remove the button that already
wasn't shown on the tree view.
As users may not fully upgrade their views or may wish to customize,
we add a fallback question title in `_compute_display_name`too.
Task-3495142
closesodoo/odoo#135853
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Vivek Pathak <vivp@odoo.com>
When a user creates a downpayent with a fixed amount, the amount is tax included. This can generate rounding issues as sometimes the amount is impossible to be reached by any base amount / tax combination. (fixed amount = 100€, tax is 21% -> 100/1.21 = 82.64 -> 82.64 * 1.21 = 99.99). This can lead to up to 1 rounding error per downpaylent line.
Until now the total amount delta was added/removed on one tax line, one receivable line and one product line. While the total amount was correctly corrected, the amount on the individual lines would be off.
On a SO with :
base | tax | tax incl
1000€ | tax_21%_a | 1210€
1000€ | tax_21%_b | 1210€
Generate 1 DP for fixed amount 200€
Invoice lines :
BEFORE:
tax | balance | price_total
base lines ----------------------
tax_21%_a | -82.64 | 100.01 <-- 0.02 correction
tax_21%_b | -82.64 | 99.99
tax lines -----------------------
| -17.37 | 0.0 <-- 0.02 correction
| -17.35 | 0.0
receivable line -----------------
| 200.0 | 0 <-- 0.02 correction
AFTER:
tax | balance | price_total
base lines ----------------------
tax_21%_a | -82.64 | 100.0 <-- 0.01 correction
tax_21%_b | -82.64 | 100.0 <-- 0.01 correction
tax lines -----------------------
| -17.36 | 0.0 <-- 0.01 correction
| -17.36 | 0.0 <-- 0.01 correction
receivable line -----------------
| 200.0 | 0 <-- 0.02 correction
closesodoo/odoo#135698
X-original-commit: d197efa60cf7c00168847ce7afcfa1741410aee1
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Downpayment might have been determined by a fixed amount set by the user.
This amount is tax included. This can lead to rounding issues.
E.g. a user wants a 100€ DP on a product with 21% tax.
100 / 1.21 = 82.64, 82.64 * 1,21 = 99.99
This is already corrected by adding/removing the missing cents on the DP invoice
but it would still be wrong when creating the final invoice (as it is based on the actual base amount + tax of the SO DP's)
opw-3466409
X-original-commit: 0a6e2d47107727040664176740535707286a1355
Part-of: odoo/odoo#135698
How to reproduce:
- open a record with an html_field (i.e. todo or a Knowledge article)
- switch back and forth with the pager or the knowledge sidebar between 2
records
Current behavior:
- traceback `this._elementHookMap.get(element)` is undefined
Expected behavior:
- no traceback
Technical explanation:
When changing the editable content (i.e. `resetContent` when changing record),
there is no guarantee that `_intersectionObserverCallback`
(intersectionObserver) won't be called before `_updateHooks` (mouseMove/resize
after a mutation occured).
This is an issue because `this._elementHookMap` may not yet have a hook element
related to the editable element which stops intersecting the document.
If such a case occurs, the next `_updateHooks` should be called when the
mutationObserver flags `_resetHooksNextMouseMove` to `true` and then after the
next `mouseMove` (or after the next resize).
Ignore the hook style update if there is currently no hook for an element which
stops intersecting.
Remove a redundant check in `_getMovableElements`
task-3506666
closesodoo/odoo#135464
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Include the 'duplicate' action in the action menu in list view. The copy_batch
method will call the copy method with a loop to keep any existing override.
closesodoo/odoo#133977
Task-id: 3456679
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Up until this commit, which view was displayed by default on mobile was
somewhat of a lottery.
Initially, only kanban views were considered as 'more adapted to mobile
devices' and used as a main fallback to display records who had a kanban
view in the window action definition.
The the concept of 'mobile-friendly view' was extended to map and grid
so that these views could take precedence over the kanban view in
specific circumstances (indsutry_fsm and timesheet_grid, both of which
are enterprise edition apps) - basically they were marked as
mobile-friendly not because they *are*, but because it was the only way
to override the kanban override.
But this comes with its lot of problems and limitations, namely that the
mobile friendly view will be found based on the order of view modes for
a window action, so if you have a window action with the view modes
`kanban,map,tree,form`, you will never be able to have e.g. the kanban
view shown on desktop by default and the map view on mobile.
This commit introduces the notion of a 'default mobile view' on window
actions so that one may decide on an *arbitrary* view mode to use on
mobile for an action - without impacting the ordering of views on other
models, etc.
Task-3460374
closesodoo/odoo#133608
Related: odoo/enterprise#46562
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the payment providers (e.g., Stripe, Adyen...)
available for payment were displayed on the payment forms. The customer
had to select one to process their payment. After that, the customer had
to select their preferred payment method (e.g., Credit Card,
Bancontact...) from a list of payment methods supported by the selected
provider over which the website administrator had close to no control.
This was making the payment forms confusing because the payment methods
were displayed sometimes more than once, if at all, in a non-controlled
order, and behind the selection of a payment provider that customers
should not have to deal with.
As the payment method was selected in an iframe or directly on the
provider's website, the information on the selection payment method was
not available in Odoo. This posed many problems, among which were the
impossibility of assessing whether a specific feature (e.g.,
tokenization, refunds, manual capture...) was available, not being able
to easily identify payment tokens through the payment method logo,
listing available payment methods on the website, sorting and
fine-grained configuration of the available payment method, subpar
payment method-specific display on the payment form (e.g., PayPal that
requires displaying a "Pay with PayPal" button), etc.
In this commit, the payment providers are thus replaced by the payment
methods on the payment forms. All contextually available (depending on
the country, currency, requested feature...) payment methods are
displayed one after the other on a single-level list and in the order
configured by the website administrator. Each payment method is
"powered by" (i.e., linked) to a single payment provider: the first one,
by model order, to support it. This allows, for example, offering the
PayPal payment method through Mollie, which charges low processing fees,
while also offering Klarna through Stripe, which supports more payment
methods but charges higher processing fees.
While doing so, the two different payment forms, "Checkout" and
"Manage", are also merged together in a new, configurable case-by-case,
payment form that is entirely redesigned to offer a better user
experience.
After payment, the information on the selected payment method is saved
on the transaction and eventual payment record and updated with the
information received from the provider.
task-2882677
closesodoo/odoo#120446
Related: odoo/upgrade#5103
Related: odoo/documentation#5717
Related: odoo/enterprise#40666
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Co-authored-by: Anita (anko) <anko@odoo.com>
Co-authored-by: Brieuc-brd <brd@odoo.com>
Co-authored-by: Valeriya (vchu) <vchu@odoo.com>
Several functions were:
- called with `await` while there are synchronous;
- declared as synchronous while they should have been asynchronous;
- declared as synchronous but their overrides were async;
- explicitly encapsulating their return values in a `Promise` when it
was unnecessary.
This commit also cleans up a few mistakes in comments and docstrings.
task-2882677
Part-of: odoo/odoo#120446
This commit mainly removes the extra indent level left over after commit
odoo/odoo@8ec2e8cf. It also cleans up purely cosmetic code styling
inconsistencies.
task-2882677
Part-of: odoo/odoo#120446
Current behavior:
If you had 2 products with different expense account and using real-time
inventory valuation, there was an error when validating the picking.
This was happening because move_vals we were trying to assign multiple
moves to one pos_order here https://github.com/odoo/odoo/blob/95cec6ea3daebce6491cc2a8a69d9688322989ba/addons/point_of_sale/models/stock_picking.py#L155
The account move is actually reserved for the invoicing of the order.
So we just need to remove that line.
Steps to reproduce:
- Create a product with expense account A
- Create a product with expense account B
- Make sure both products are set to real-time inventory valuation
- Activate ship later in the PoS
- Open the PoS and add both products to the order
- Validate the order with ship later and no invoice
- Close the PoS and try to validate the picking of the order.
opw-3428033
closesodoo/odoo#136254
X-original-commit: a2c8ea0adbd93cb9d178977f73e93492e84dfec3
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Use the same method and date used to compute the rate on aml field currency_rate
closesodoo/odoo#136230
X-original-commit: adae60fc532cf6a853815f840cb49e93eb008cb7
Signed-off-by: Josse Colpaert <jco@odoo.com>
Steps to reproduce
==================
- Use a mobile viewport
- Create a quotation
- Add an order line
- Set a packaging
-> The Packaging Quantity field is missing
The same happens on purchase orders
---
opw-3504829
closesodoo/odoo#136213
X-original-commit: c5d665cc2b43a0040c3f5644265e74048c3d5ded
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Since the new model (PR: odoo/odoo#114024), updating a record no longer
triggers a deep render and therefore no longer triggers the onWillUpdateProps
for Field components.
The goal of this commit is to adapt the usage of onWillUpdateProps
in Field composents in order to fix the bugs introduced by the RelationalModel
closesodoo/odoo#135842
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This solves the following problem:
- Add 150 records with 2 activities each (ex. A call and a to do)
- Go to the activity view (ex.: event through the systray) and clear filter
- Only 50 of the 150 records are displayed (instead of 100)
- Going to the next page, only 2 are displayed (instead of ~50) (will depends
on the data already present)
Technical notes:
Not all activities were displayed because the search limit was applied on the
activity search instead of searching all activity related to the records.
The method fetchActivityData was doing half of the job because it was not
assigning the activity data fetch on the server to the instance variable
activityData, which was causing strange behavior when clicking on next page. To
simplify and correct the code, that logic has been moved to that method instead
of relying on the caller to do that assignation.
Task-3508744
closesodoo/odoo#135651
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The activity view pager test is improved to use the actual get_activity_data
mock rather than checking that it is called with the right parameters. Thanks
to that, we also check that the activities are displayed. To ensure that the
pager influence only the records displayed and not the related activities, we
set up test records with 2 activities each and check that there are 2 times
more activities displayed than the number of records.
Task-3508744
Part-of: odoo/odoo#135651
[A previous
commit](https://github.com/odoo/odoo/commit/5ca1da8ab33d4dd6a9ed0b6737e5d19f1a3ac9d2)
introduces a new attribute `display_type`, `multi`, which allows users
to define extra-options to products. But this option was only available
in Sales.
This commit allows eCommerce users to use this new attribute in the
online shop.
task-3497046
closesodoo/odoo#135174
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Purpose
=======
Add the possibility to only synchronize one specific event of a user calendar instead of syncing the whole calendar.
See sub commits for more details.
Task-3285601
closesodoo/odoo#133921
Related: odoo/enterprise#46688
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Add a helper method to know when the user calendar
is fully synced to Google Calendar, meaning when
API calls can correctly be performed.
The user calendar is considered fully synced if the
Google API is correctly configured in the settings
(Client ID / Secret) and the user has synced its
calendar with its Google Account.
Task-3285601
Part-of: odoo/odoo#133921
Add a 'google_meet' value for the event videocall location
to make the difference between a custom videocall link and
a google meet one.
Task-3285601
Part-of: odoo/odoo#133921
Purpose
=======
Add the possibility to only synchronize one specific event of
a user calendar instead of syncing the whole calendar.
Specification
=============
In certain cases, we do not want to synchronize the whole user
calendar with all the events and recurrences but only a specific
event. For example, in appointment, to retrieve the generated
google meet url of a specified event.
To perform the single event synchronization a synchronization
token is needed, meaning we cannot do a single event
synchronization prior to a full calendar synchronization as it
is the full sync which generates the temporary sync token.
To prevent the need of doing a full sync before a single event sync,
the permanent synchronization token is been used instead of
the temporary one when performing a single event synchronization.
Task-3285601
Part-of: odoo/odoo#133921
In this commit
==============
- Added the discount fields to the vendor pricelist and PO line models,
making them optional and hidden.
- Implemented automatic filling of the discount field on the PO line when
the unit price is sourced from the vendor pricelist.
- Implemented a mechanism to automatically populate the discount field on the
PO line when the unit price is fetched from the vendor pricelist.
- Modified the pricing logic to ensure the discount is applied to the
tax-excluded price.
- PO confirmation process to check if a pricelist already
exists for the vendor. If not, a new pricelist line is created, including the
discount if it is present.
task - 3380306
closesodoo/odoo#126804
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
In this commit, I have made changes from 'Advantage' to 'Benefit' because I made
modifications in the 'hr_contract_module'. This group is being utilized in
'hr_contract', so I updated the file accordingly.
task-3374616
closesodoo/odoo#127207
Related: odoo/upgrade#4852
Related: odoo/enterprise#43262
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Co-authored-by: Kuldeep Singh<kusi@odoo.com>
Steps to reproduce:
-------------------
- add an allocation for an employee;
- add a leave with this allocation;
- validate the leave;
- refuse the leave;
- in action menu, click on "Time off Analysis by Employee and Time Off Type".
Issue:
------
The report does not take into account refused allocations and leaves.
Solution:
---------
Add a condition to take a number of days equal to zero
if the allocation or leave is in a refused state.
Handled the case where no record is found for leave
(with `COALESCE` because `value - NULL = NULL`).
opw-3503617
closesodoo/odoo#136217
X-original-commit: 4c73d4a7d5cec388177e2703ac9b0a42de8c12c8
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
PR #134787 was introduced to fix an error with product template
attribute values. However, when moving `ptavId.concat` into the if
statement, it missed the fact that the function returns a copy rather
than editing in place.
This means that the line achieved nothing.
opw-3513820
closesodoo/odoo#136216
X-original-commit: 3b823f0ba76b53d59cd6702836bef40ab3f484cb
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Andrew Gavgavian (andg) <andg@odoo.com>
there is a loophole that allows the same third-party check to be used
for multiple outbound payments. This issue causes data inconsistencies
and disrupts the expected behavior of the financial workflow, thereby
undermining the integrity of the accounting processes.
In order to address it a constraint was introduced on the
l10n_latam_check_id field. This constraint is triggered whenever
a payment transaction involves the use of 'out_third_party_checks' as
the payment method. The system now conducts a search to identify any
pre-existing payments that might be using the same third-party check.
If a duplicate use of a check is detected, a ValidationError is promptly
raised, effectively blocking the transaction.
Task-3503556
closesodoo/odoo#136202
X-original-commit: 462614774e0134b805a87e45c7327f7359736bee
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Mohamed Erradi (moer) <moer@odoo.com>
This commit excludes off-balance accounts from appearing in tax
repartition lines.
Previously, off-balance accounts were included in the selection, which
was causing confusion and unnecessary clutter in the interface.
The need for this change was raised due to the observation
that off-balance accounts are never actually used in tax repartition
scenarios.
Including them only complicates the account selection process without
adding any functional value
closesodoo/odoo#136196
X-original-commit: 77871dd434a912fab41e6cec674c272fe37bcf1d
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Mohamed Erradi (moer) <moer@odoo.com>
Steps to reproduce:
1. Have 2 companies, and select the one w/ the highest ID
2. Create a new product tracked by lot + expiration date
3. Receive product
4. Set the received lot's expiration and alert dates in the past
5. Inventory > Operations > Run scheduler
Before this commit:
An activity is created on the lot for OdooBot,
despite the product's responsible set to the current user.
It happens because the default value for `responsible_id` is the current
user, but the value is only set for the current company. When the
scheduler runs, it doesn't set the company; therefore, it takes the
product's responsible user for the company with the lowest ID, which is
not set.
After this commit:
The activity is created for the product's responsible user using
the lot's company.
opw-3489340
closesodoo/odoo#136172
X-original-commit: dacfa84486c3251f503ef2a36b56006471961123
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Walravens Mathieu (wama) <wama@odoo.com>
This traceback arises when the user clicks the 'Create Employee' button
from 'recruitment'
To reproduce this issue:
1) Install 'hr_recruitment' and 'Website'
2) Open 'Recruitment' and click on the 'Job Page' button of any published
'Job Position'.
3) Click on ' Apply Now ' and apply for that job.
4) Now open that job application from 'Recruitment/Application/By job positions'
5) Change the stage from 'New' to 'Contract Signed'.
6) A button 'Create Employee' will appear, click on that.
Error:- "psycopg2.ProgrammingError: can't adapt type 'res.country'" will appear.
On the 'create_employee_from_applicant' method, the employee record is created
by using '_get_employee_create_vals' method.
In that '_get_employee_create_vals' method, 'private_country_id' is created
from 'address_sudo.country_id' which is an object.
See:-
https://github.com/odoo/odoo/blob/a5911b7d560a4e259570cf9d46fff5fb286e3d62/addons/hr_recruitment/models/hr_applicant.py#L587-L605
Here in the above use-case instead of passing 'ID', an Object is passed.
Which leads to the above traceback.
Sentry-4450017781
closesodoo/odoo#136121
X-original-commit: e462e9891fa909b04a21aa7b11e8b8f26688cc04
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Altaf Shaik (alsh) <alsh@odoo.com>
Before this commit, cids in the url (in the hash part) were
separated by a comma, which was encoded by encodeURIComponent as
it is not considered as a safe character, resulting into "%2C"
appearing in the url in between company ids. This was kind of ugly
and made the url a bit hard to read.
This commit uses "-" as separator for cids, which is a safe
characters [1] to use in the url and which is thus left untouched by
encodeURIComponent.
AL request.
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent#descriptionclosesodoo/odoo#136104
Related: odoo/enterprise#47723
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
- When a new pivot is added, and if the user has already defined
field matching in a previous pivot, the new pivot will inherit the
field matching from the previous pivot as default values.
- If multiple pivots are added from different models, will check the
model of the new pivot against previous pivots. If the model matches,
the field matching from the matching previous pivot will be used. If
no matching model is found, the field matching will be left empty.
- Same will also done in case of list and odoo chart.
closesodoo/odoo#135841
Taskid: 3373163
Related: odoo/enterprise#47570
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
`RecordSet` relations were rare and not worth having them. Turning
them into `RecordList` has no drawbacks.
To simplify many relations to a single relational field,
`Record.List()` was renamed to `Record.many()`, and `Record.Set()`
has been removed.
closesodoo/odoo#134884
Related: odoo/enterprise#47745
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
- Split d.ts files in `@types` folders that are close to
where the definitions of model & patches.
- Update jsdocs of discuss models to be fully type, including
model patches
When defining a new discuss model or a patch, should define a
`@types/models.d.ts` file. It must make use of module `models`
to define interface with model name:
```ts
declare module "models" {
import { Thread as ThreadClass } from "./thread_model";
export interface Thread extends ThreadClass {}
// necessary to propagate types to relations
export Models {
"Thread": Thread,
}
}
```
When defining a patch, should also define a `@types/models.d.ts`
to augment the interface of the model at hand:
```js
patch(Thread.prototype, {
setup() {
this.pinnedMessages = Record.Set("Messages");
}
});
```
```ts
declare module "models" {
import { Message } from "models";
export interface Thread {
pinnedMessages: Set<Messages>,
}
}
```
Part-of: odoo/odoo#134884
With the introduction of relational fields on discuss models,
which makes it easier to manage relations between discuss records,
we are incentivized to define all discuss relations in the models.
Some services managed relations with their own datastructure.
For example, pin_message service uses some Maps and Sets to model
messages pinned on channels. This is cumbersome to manage deletion
of records by hand... And also the name of attributes in the service
are too long, which shows they are not placed in the right context
(= in a dedicated service rather than in models).
This commit turn these relational data in pin_message service into
new relational fields on Thread and Message models.
```js
patch(Thread.prototype, {
setup() {
this.pinnedMessages = Thread.Set("Messages");
},
});
```
For type inference of the discuss model patches, we rely on module
augmentation of TypeScript with interfaces: we define an interface
for the patch of a given model, and we combine the type of this
"patch" interface with the original Model type in the listing of
Models types:
```ts
declare module "models" {
import { Persona } from "./persona";
import { Thread } from "./thread";
export interface Models {
"Message": Message,
"Thread": Thread & Partial<Thread_Patch>,
}
export interface Thread_Patch {
pinnedMessages: RecordSet<Models["Message"]>
}
}
```
That way, whenever we use a record e.g. from a one relational field,
we have proper typing for the patches:
```js
class Message {
originThread = Record.one("Thread");
}
message.originThread; // Thread & Partial<Thread_Patch>
message.originThread.pinnedMessages; // RecordList<Messages>
```
So whenever you adapt a discuss model patch or add a new one, make
sure to register new props in an interface of "models". Other devs
will be grateful towards you!
------
Note that the previous implementation of Relational fields on discuss
models was not robust enough with patching, notably with the
implementation details of `@web/patch()` function. Instead of using
`Object.defineProperty` on the model class prototype of each
relational field, we now use a proxy. This prevents the proxy hook
to be shadowed by the patches. This also allows to support a new way
to delete `Record.one()` relations with the `delete` keyword.
Part-of: odoo/odoo#134884
Introduce many relation by means of `Record.List()` and
`Record.Set()`. `Record.List` makes a data-structure similar
to JS Arrays, whereas `Record.Set` makes a data-structure similar
to JS Sets. Instead of storing objects, they store local ids
of records.
Note that some methods that return a collection return a native
collection, not a record collection. For example,
`RecordList.filter()` returns an array, not a `RecordList`.
This allow limiting using these special collections only when
handling relations, not collections in general.
Also note that the `Record.List` and `Record.Set` both accept either
native collection or record collection as setter argument.
```js
class Thread extends Record {
messages = Record.List("Messages");
followers = Record.Set("Follower");
}
// ...
thread.messages = messages;
thread.messages.push(message);
thread.messages.filter((msg) => !msg.isEmpty);
thread.followers.add(follower);
```
These relations allow to normalize discuss store further, improve
code readability with simpler field names, and also prepare for
future improvements on models such as simpler python formatters,
simpler Record.insert flows, relational fields that automatically
reflect on record deletion, etc.
Part-of: odoo/odoo#134884
This allow storing only the local id internally, and there are
automatic `get`/`set` to get the related record. This prepares
support of record deletion that would automatically delete
all relational fields, in a follow-up PR.
```js
class Message {
author = one("Persona");
}
```
Relational fields can be used to uniquely identify records:
```js
class ChatWindow {
static id = "thread";
thread = one("Thread");
}
```
Part-of: odoo/odoo#134884
Before this commit:
The `mailing_filter` widget used to take the 2nd occurrence of a
many2one(selection) field and hide it in certain conditions, as it was assumed
that it is the field having the widget. Thus when there is more than 1
occurrence of a many2one field in the form view (before the field with the
widget), it used to hide random fields instead of targeted field.
After this commit:
The `mailing_filter` widget will only target the field with the widget, hence
solving the issue at hand.
Task-3430510
closesodoo/odoo#136094
X-original-commit: 4f5b8c47be4077cdaf7837062f518b7aef529d71
Related: odoo/enterprise#47678
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
having PO
Step to reproduct:
-User A with Admin Project Access Right and no Pucharse Acesss Right
-PO and Project have same analytic_account_id, with PO analytic_account
will place in 'analytic_distribution'
-User A then go to Project Update -> Access Error happen
=> Expected behaviour is to let Project Admin access it
Solutions is to let he/she see it by adding sudo() only
closesodoo/odoo#136045
X-original-commit: 249aaac7bd1a13d62c947cddb1835772659aabff
Signed-off-by: Audric Onockx (auon) <auon@odoo.com>
=== ISSUE ===
With Milk, our primary buttons received a fresh lifting in term
of design,with different designs according the state the button is in.
Before that, our buttons were green with a white text on it,
and the behavior was identical on `hover`. This allowed us to force
a `color: white` when it was needed, since the background always matched
WCAG contrast standards.
Since the 16.3, these buttons are on a dark background,
and that background becomes light when in `active` state. That means we
cannot use white on these buttons.
=== AFTER ===
We set the color of the link inside the button to `inherit` in order to
fix the active state behaviour.
Note that this should be improved when reworking the widget since having
a link inside a button is not really expected. Instead we should use a
link that allows different actions.
task-3354844
part of task-3326263
closesodoo/odoo#135996
X-original-commit: 572288ccf2244df23c031dd88c47d2807fd06c47
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
the filename field shouldn't be 'false' but an empty string when
the binary file is deleted.
closesodoo/odoo#135894
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
1) fix automatic creation of documents when attachments are added
to product templates/variants chatters
2) fix duplication of documents
3) fix deletion of documents
Delete child record before deleting parent record.
Before this commit, when trying to delete a product document,
we deleted the parent record first, before trying to delete
the child, which had been deleted (cascade) already.
Part-of: odoo/odoo#135894
