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
In DocumentViewer, we need to generate google slide urls.
In this commit, we're going to create the getGoogleSlideUrl utility that
generates a google slide url.
closesodoo/odoo#135851
Related: odoo/enterprise#47573
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The purpose of this commit is to simplify PdfViewerField by removing its
unused props. No use of the "pdf_viewer" widget uses "filename" or "preview_image".
Part-of: odoo/odoo#135851
In this viewtiverse, the heroes remove the context dependencies for
`get_views`, from the views and python fields (such as domain). To reduce
inconsistencies and the number of rpc.
Current issues:
* There may be inconsistencies in views at the JavaScript level. Some
overrides modify the behavior of get_views or domains on fields via
context keys, therefore by changing the action, the rendering may be
different. However, these views are cached. However, the cache key
(Javascript) does not reflect the entire context, and requires additional
post-processing from the server.
* Multiple rpc for the same rendering. get_views being dependent on the
context, as soon as it changes, a new rpc is performed. In most cases,
when JavaScript needs the same view, there is no change depending on the
context, the rpc is useless.
* Inconsistency when rendering subviews, some views could be different
depending on the context, this context can be modified in the view itself
via the context attributes. However, the JavaScript client does not redo
an rpc for each change of these sub-contexts. Therefore the result may be
inconsistent.
Solution:
Limit as much as possible the number of context keys provided when calling
get_views, and use the context provided as a cache key. The authorized
keys are 'lang' and '*_view_ref'. For the cache key, options are added in
the get_views method.
Instead of using the context, it is inserted into python expressions.
This will be evaluated by JavaScript and thus avoids inconsistencies.
task-3414108
task-3414068
closesodoo/odoo#135145
Related: odoo/enterprise#47584
Signed-off-by: Raphael Collet <rco@odoo.com>
This PR resolves a bug in the self linked to the demo data.
Steps to reproduce:
Create a new Restaurant session
Open mobile menu for Restaurant
Make an order in the mobile menu for a table
Reload the page where the open restaurant session is.
[BUG] The ball telling if an order is sent to the kitchen or notbecame black.
[EXPECTATION] The ball telling if an order is sent to the kitchen or not is red.
closesodoo/odoo#134777
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
In this commit, next to UX changes, we make some changes in order to
increase time off dashboard usability.
In particular, - New Allocation Request - was moved to Time Off Card.
Now user can also ask for specific time off type allocation from
the time-off-card-popover.
Moreover, we fix the following issue:
Previously allocation name was not computed on create. We also fix the
computation of the name, in case time of type is not filled in yet.
With the later change, test_allocation_request test was failing as
first the name field was assigned, then holiday_status_id;
Which caused for the name field to be recomputed and assigned to False.
As the field is required, leave_form.save() was raising an error.
task - 3389144
closesodoo/odoo#132187
Related: odoo/enterprise#47651
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, each module had its own logic regarding payment
flows in the portal. With this commit, we enforce that if the user is
logged in, they see their tokens, while logged out users see the tokens
of the customer (the contextual partner).
task-2836870
closesodoo/odoo#124631
Related: odoo/enterprise#42999
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Some businesses requires customers to pay a down payment in order
to confirm the order. In the case of odoo today this implies to:
- sending a payment link
- waiting & checking if the payment has been done
- confirming the order
- creating the down payment invoice
A lot of time consuming manual operations with a high risk of errors.
This commit introduces the functionality for sales orders to be
confirmed on down payments and automatizes the flow to minimize the
errors due to human manipulation.
Task - 3087716
Part-of: odoo/odoo#124297
Co-authored-by: Victor Feyens <vfe@odoo.com>
In this commit, we add images on demo categories to make the demo more
realistic but also change a bit the design of the category selector.
closesodoo/odoo#134621
Signed-off-by: David Monnom (moda) <moda@odoo.com>
When loading a registry from the route with auth="none" and where module
'website' is set as 'to install', request.env will be None, and install will
crash as follows:
Error:-
AttributeError: 'NoneType' object has no attribute 'context'
reference of previous commit-
https://github.com/odoo/odoo/commit/0ebf849b8e0de33d3b6e7e06c66189591dc7a72c
sentry-42474563
closesodoo/odoo#136096
X-original-commit: ca43e03e6f510520e874b2a8bba092ac9a7f2453
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
PR #105873 added computed indexes on the `mobile` and `phone` commits
for the benefit of `phone_mobile_search`, however it created both
indexes to work on the `phone` field as source, rather than whichever
field they were named after and partial for. As a result, the index
has no effect when searching on `mobile`.
closesodoo/odoo#135878
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
With the removal of the repair.line model, we must now use the stock.move model instead.
The smart button on stock.lot should only show repair orders where the related product is used as a component however it shows all repair orders containing the product.
Now, it will correctly only select repair orders where the product is a component based on the repair_line_type of the stock.move.
Also renamed repair_order_ids and repair_order_count for easier differentiation with new fields.
Part-of: odoo/odoo#129933
added a contextual action to call action_plan_with_components_availability()
if each component line of a production order has a forecast_expected_date,
the date_start of the production order will be the latest forecasted date
task 3395161
Part-of: odoo/odoo#129933
Added a todo count field on the button where the lot is the product being repaired.
Changed the texts to better fit the buttons.
Part-of: odoo/odoo#129933
When the blacklist table is filled with multiple thousands of records
searching the `is_blacklisted` field leads to a domain like
`[('id', 'in', [thousands_of_ids])]`. This can create a multiple megabytes
sql query.
Using inselect allows to avoid that issue.
Task-3328210
closesodoo/odoo#136089
X-original-commit: e00dce5edc1e4e0452a9add775ef46a1c993a17a
Related: odoo/enterprise#47677
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit:
- Select a course from the website, and click 'Add Content'.
From the 'Add Content' window, click 'Video'.
- The description with the title 'On Vimeo' is not up to date with
Vimeo privacy management.
After this commit:
The description is now up to date.
task-3458724
closesodoo/odoo#136083
X-original-commit: 4a1d2a2726ce83edbf28dd478c60a3e6f67d4470
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This report allows an HR manager to quickly see the status of employee's certifications
red: expired, yellow: expiring in 3 months or less. There are also 2 filters for those
situations.
task 3384857
closesodoo/odoo#126438
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
All account.tax weren't delete when we reload the chart template.
It was caused by the fact that we forgot to add the active_test=False
in the context to delete all the taxes (and not only the actives).
This thing caused an issue where an sql constrains was trigger.
This fix comes from another PR (https://github.com/odoo/odoo/pull/132360)
that doesn't solve properly the issue.
closesodoo/odoo#136081
X-original-commit: a92f347318415492357413c577e666785c2cb8a4
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
The way the `ignore` property is implemented means that nested draggable
elements under a single element matching the `ignore` selector will all be
disabled.
In Knowledge, the sidebar allowing to move articles around has nested draggable
elements that the user should be able to move around, under other draggable
elements that should stay in place (depending on access rights).
Therefore, this commit introduces another way to disable dragging with the
`preventDrag` property which is a function that receives the dragging candidate
and returns a boolean to indicate whether the element can effectively be dragged
or not in its current situation.
task-3456741
closesodoo/odoo#135981
X-original-commit: eb302dbf48500b2eee61a0efb865868866fb454b
Related: odoo/enterprise#47640
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Damien Abeloos (abd) <abd@odoo.com>
purchase_stock, point_of_sale
What are the steps to reproduce your issue?
When Odoo.sh runs unit tests on a development branch,
it tests the code in the MRP module for rounding errors.
What is the current behavior that you observe?
I had a customization that introduced a rounding error in the standard MRP module.
When the unit tests ran on the development branch, I got a traceback.
What would be your expected behavior in this case?
The rounding error should be reported as a failed test with a message. No traceback.
opw-3454998
closesodoo/odoo#136052
X-original-commit: c4b5148be0819eeef8ce7e12cdc7f1d45174fe65
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Gaetan Vanden Bergh (gavb) <gavb@odoo.com>
amdi-odoo