As described in #129974, the colorpicker cannot cache a promise
protected by `useService`. #129974 fixes the issue by through non
idiomatic practice (calling a service that is not protected by
`useService`). This commit fixes the issue idiomatically.
This commit caches the promise directly from a service and removes the
caching code from the `ColorPalette`.
task-3446691
closesodoo/odoo#130789
X-original-commit: 1d2e54088b0f0e28464ab6aa884fb2e1110e8e04
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This error occurs when the user manually attempts to change the mimetype of the
attachment, and then the base function `_postprocess_contents` tries to
determine the type and subtype of the attachment.
Error: `ValueError: not enough values to unpack (expected 2, got 1)`
To address this issue, this commit introduces a check for the mimetype of the
attachment before attempting to determine its type and subtype.
sentry-4283372480
closesodoo/odoo#131333
X-original-commit: fade78ed98e6902ab5465e40d2b1bf7aa282688b
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Saurabh Mishra (sami) <sami@odoo.com>
The "test_active": False context of the field specifies that this field
will ignore whether a record is active or not when fetching it.
Due to recent changes in the javascript, the "test_active": False
context of the tax_ids field on the account move model is propagated
through into the name_search query. This means that inactive taxes
appear in the dropdown when selecting a tax.
This is an issue as there are a few localisations that hide a number of
their taxes by default (by making them "inactive").
The solution is to add the key, value pair "active_test":False to the
context of the field on the view, effectively overriding the context
that gets used in the name_search query, thus only retrieving active
taxes.
closesodoo/odoo#131212
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
*: website
Some specific media items are meant to be editable even though located
in non-editable environments. The typical case in 15.0 is the website
"Team" snippet: it is made of multiple bootstrap rows, each containing
a column with an image and a column with texts. The columns with the
image are only meant to hold that image, it was therefore marked as
non editable to prevent users adding text in there by mistake... but the
image is still meant to be editable. See [1], later fixed by [2].
The problem now is that the system that [2] had to use is quite messy:
the column is marked non editable thanks to the `o_not_editable` class
but the inner images were to be declared editable via some custom JS
method overrides (`_getContentEditableAreas`). The debate about if we
should keep a class-based system and/or a method-override system will be
left to master. This commit although comes with an uniformisation about
this, introducing a new class to declare "an editable media despite its
non editable environment". This is not a counter-part of the class
`o_not_editable`: we do not want the media to be marked with the
`contenteditable` attribute. Indeed, this is actually required since [2]
was not enough to solve the problem. See those steps:
- Add a company snippet in your page
- Change one of the images by an icon
- (Save / Reenter edit mode)
- Try to change the icon again / edit its options
=> You can't. Indeed [2] relied on the media being an image to re-enable
edition on it... but even if it did not, it would not have been enough.
Indeed, icons are forced to being `contenteditable="false"` by the new
editor library (since 15.0 then), last update on that at [3].
We thus needed a different way to differentiate editable media, hence
the introduction of the new `o_editable_media` class.
Note: this system is not perfect, but so is not the whole system about
determining what is editable or not at the moment. In this case, it may
exist cases of a media marked with the class to be editable but end up
in an environment which is not editable by force (xpath somewhere etc)
... and ends up being editable anyway. Most cases work though and at
worse it will be about a non editable image being editable but not
possible to save in very rare cases. As advertised, the whole system
about what is editable or not should be improved.
[1]: https://github.com/odoo/odoo/commit/30db617bc8ff7727f40d7ef58c6578e84a13f284
[2]: https://github.com/odoo/odoo/commit/61270ee8bffb6e85f8ff0d19c7a3889fdce2f486
[3]: https://github.com/odoo/odoo/commit/7646429e894f28f398b7b212e893822c06c7b03d
task-3226172
closesodoo/odoo#131139
X-original-commit: 436265e815684046a37a8b80e4cd520c2bd637f0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Commit [1] refactored the event handler code in charge of handling
double click on media elements to edit them. A mistake was made making
the code consider inner elements of the media instead of the media as a
whole when clicking on it.
Steps to reproduce:
- Enter edit mode on the homepage
- Add a text-image snippet
- Change the image to a video (after dblclick on the image for instance)
- Try to change it back with a dblclick => it does nothing
[1]: https://github.com/odoo/odoo/commit/8ca115b3b9dfe87b59b6b064a4d85ea152d9214c
X-original-commit: 4b47ae0022a3e50d53dc02e399412585fc2131ef
Part-of: odoo/odoo#131139
Before this PR, when moving the snippet's position, `d-none` gets added
which should not.
With this PR, removing the `this.$target.addClass('d-none')` from
`cleanForSave` method as it was adding `d-none` unnecessarily while
moving snippets position. The fact is snippet will be hidden if the
current user has no access to the mail group. So that case will be
handled using controllers route `/group/is_member`, if this return email
of the user, snippet is visible else the user has no access to the mail
group so we remove the snippet.
task-3107451
closesodoo/odoo#131131
X-original-commit: 51e92d022d50a7a4adaca872d42849eeaf64f88d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Usecase to reproduce:
- Set operation time base on last workorder
- Create 2 MO
- On first MO, set 15min as duration
- On second MO, set 10min as duration
- Validate both MO at the same time
- The duraction expected on the operation could be now 10 or 15min
It happens because the search in the compute is only base on date.
And when both MO are validated at the same time, it's not enough
closesodoo/odoo#131307
X-original-commit: cad75ac78b61046352c39d3f3b7717cfbad42c8b
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
PURPOSE
=======
Starting from 16.0 we introduced some reports to log skills history, skills evolution.
It means that the skill model is linked to another model, preventing us to delete it.
Usually, we use the message "link to x, archive it instead", but archiving a skill will only be possible from v17 (new task)
So, we need to be able to delete a skill on v16
closesodoo/odoo#131300
Taskid: 3456843
X-original-commit: d9672b55e7a596778fd542541f39e5216c06cb40
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This PR cleanup service typing:
* Introduce `addons/mail/tooling/type/services.d.ts` to automatically type
services imported by `useService` hook.
* Correctly type service constructor, setup and start functions.
* Remove now useless `@type`.
* Removing `Object.assign` for services variables.
* Type OdooEnv.services to services.
closesodoo/odoo#131192
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Prerequisites -->
1) Login with a user with just Inventory/User access rights
2) Product A with purchase policy set to `on ordered quantities`
3) Product category of A set to `AVCO` costing method
Steps -->
1) Create+confirm a PO with product A and create and confirm vendor bill
2) Switch to Inventory/User user
3) Try to validate picking
4) Access right error
This occurs due to the fact that `Inventory/User` does not have access to s`tock.valuation.layer` or `account.move.line`.
Solution -->
Add sudo to the lines where accesses to SVL and invoice lines are made.
opw-3357028
closesodoo/odoo#130929
X-original-commit: 8d2a77d1bdbe8f865d8f7177801786617e10058f
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
RATIONALE
We plan to move from a single alias-domain configuration to a multi company
enabled support for alias domains and aliases. First step to prepare this
change is to cleanup alias usage through various Odoo addons.
ALIAS USAGE CLEANUP
Cleanup alias usage and definition. Prepare code to ease future changes and
improvements. Notably
* add a 'alias_email' computed field on the mixin allowing to have the
complete alias email when set, and False in case it is inactive or linked
to an inactive alias domain;
* remove unnecessary alias_id field definition when just the help differs
from the standard definition coming from the 'mail.alias.mixin';
* use fields coming from 'inherits' instead of using alias_id and its sub-
fields; notably use 'alias_display_name' and 'alias_email' fields;
* remove useless custom code and management;
* improve alias parameters support code in configuration parameters;
ALIAS MIXIN WITH OPTIONAL ALIAS_ID
Some models would like to use the 'mail.alias.mixin' but it creates an alias
for each record in the parent model. This leads to a lot of unused aliases
if only a subset of those records really use aliases i.e. a lot of aliases
with 'alias_name' being 'False'.
In this commit we introduce a new mixin 'mail.alias.mixin.optional' that
behaves like the old 'mail.alias.mixin' but without having the 'alias_id'
field required i.e. without the "inherits". When creating a record without
giving an 'alias_name' no alias is created.
In this PR we use it notably to remove custom code in account journal model
and make it more standard. Using it in more models will be done later, but
it is a candidate to cleanup unused aliases related to discuss channel model.
ALIAS NAME SANITIZE
Currently there is a constraint on alias name as we allow only a subset of
valid latin characters in it aka `[a-zA-Z0-9!#$%&'*+\-/=?^_`{|}~]`. There
is also an automatic sanitize of alias name at create / write that replaces
any non-word characters by an hyphen. This sanitize is stricter than the
constraint and it is not really coherent.
In this commit we make the sanitize inlined with the constraint, allowing
more characters to go through the 'mail.alias.mixin' cleaning pass notably.
Enforce that void alias names are forced to False to avoid any constraint
issue. Sanitize method is now independent from the check method, to avoid
calling multiple times the sanitization as it is often used for other checks.
MISC
Lint / reorder code, prepare future changes. Add tests, notably for alias
name sanitize and management.
Provide various fixes, see sub commits for more details.
LINKS
After odoo/odoo#130768 and odoo/enterprise#45204 this is another preparation
for multi-company aliases (see odoo/odoo#76734 and odoo/enterprise#20983).
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
closesodoo/odoo#130632
Related: odoo/enterprise#45118
Related: odoo/upgrade#5012
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Current usage of aliases in 'account.journal' model is a bit low-level and
is done by hand. This is notably due to some specific requirements for
accounting: batch install of journals with aliases with names holding
non-ascii characters, easy support of multi-company when creating aliases
with similar names, specific heuristic to generate alias name to be
understandable if sanitize / encoding leads to stripping lot of name parts.
Inherit from the 'mail.alias.mixin.optional' that automates management of
alias without requiring the "alias_id" field. It handles aliases like other
Odoo models, notably for security, readable / writable field, alias reset
or values synchronization. It allows to remove unwanted sudo().{write/unlink}
and have code more aligned with current standards.
Using this mixin allows to skip the inactive alias creation and instead keep
a void m2o. When having a lot of journals to create for some COA this helps
saving DB space and reduce number of inactive and useless aliases.
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
Cleanup alias usage and definition. Prepare code to ease future changes and
improvements. Notably
* add a 'alias_email' computed field on the mixin allowing to have the
complete alias email when set, and False in case it is inactive or linked
to an inactive alias domain;
* remove unnecessary alias_id field definition when just the help differs
from the standard definition coming from the 'mail.alias.mixin';
* use fields coming from 'inherits' instead of using alias_id and its sub-
fields; notably use 'alias_display_name' and 'alias_email' fields;
* remove useless custom code and management;
* improve alias parameters support code in configuration parameters;
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
Some models would like to use the 'mail.alias.mixin' but it creates an alias
for each record in the parent model. This leads to a lot of unused aliases
if only a subset of those records really use aliases i.e. a lot of aliases
with 'alias_name' being 'False'.
In this commit we introduce a new mixin 'mail.alias.mixin.optional' that
behaves like the old 'mail.alias.mixin' but without having the 'alias_id'
field required i.e. without the "inherits". When creating a record without
giving an 'alias_name' no alias is created.
In future commit, we plan to use it notably to remove custom code in account
journal model and make it more standard. Using it in more models will be done
later, but it is a candidate to cleanup unused aliases related to discuss
channel model.
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
Currently there is a constraint on alias name as we allow only a subset of
valid latin characters in it aka `[a-zA-Z0-9!#$%&'*+\-/=?^_`{|}~]`. There
is also an automatic sanitize of alias name at create / write that replaces
any non-word characters by an hyphen. This sanitize is stricter than the
constraint and it is not really coherent.
In this commit we make the sanitize inlined with the constraint, allowing
more characters to go through the 'mail.alias.mixin' cleaning pass notably.
Linking some bug fixes about that subject (notably due to 'account.journal'
model that uses aliases without going through the 'mail.alias.mixin', hence
allowing to see differences between sanitize and constraint):
* odoo/odoo@33bd1a951a : non ascii aliases when installing COA and generating
journals automatic email aliases;
* odoo/odoo@e08ee893d1 : left-part should not begin or end with dots as well
as containing dots sequence;
* odoo/odoo@f1215389e8 : prevent international char in aliases;
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
Improve tests related to alias management in 'account.journal' model. In
order to support multi-company based alias domains we are going to cleanup
custom management of aliases in journals, moving towards a standard usage
of 'mail.alias.mixin'. This commit prepares this change by adding more
complete tests about current behavior of aliases.
This notably improve tests from odoo/odoo@339cdffb68 where the purpose is to avoid
issues when installing a COA, aka creating journals in batch.
This also adds tests for odoo/odoo@400b686027 where we ensure alias defaults are
synchronized with journal configuration.
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
Currently ICP parameter clean and check is done at create / write override.
However it should be done at ``set_param`` level to avoid messing with the
specific behavior of ir.config_parameter with falsy values.
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
In addition to checking conflicts with existing aliases, we have to check
that given name list also contains only unique names. Otherwise creating
in batch with duplicates raises the SQL unicity constraint instead of the
expected UserError.
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
Aliases should be unique except when they are empty. Indeed each valid email
address should be unique, as it targets a specific behavior e.g. creating
a task in a project or a ticket in an helpdesk team.
For that purpose an SQL constraint exists that enforces the unicity. Null
values in DB are not considered as being the same, meaning we may have
multiples aliases with Null values in DB.
When voiding the alias we may end up with a void string, which is not the
same as giving False to the ORM in term of DB storage. Multiple void strings
break the unicity constraint where multiple False strings do not.
In this commit we therefore enforce that void alias names are forced to
False to avoid any constraint issue. Sanitize method is now independent
from the check method, to avoid calling multiple times the sanitization
as it is often used for other checks.
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
CODE LINT / CLEANUP
Reorder fields definition per main usage: definition, owner, parent, gateway
configuration. Order computed fields accordingly.
Rename some methods (notably constrains), move an inner sanitize method as a
model method to allow its future usage.
Perfom a quick linting of code, simplify some lines.
TESTS
Add some tests related to alias management, notably copy, and multi-company
models using aliases. Those will help when moving to multi-company support
for aliases.
Add tests for current sanitation / cleaning of alias names and alias domain
parameters, to be more precise about accepted / unallowed characters, support
of unicode, ...
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
before this commit, in the forum post form view, the
closing related fields, is visible even if the post
is not closed and question field should not be shown
in the parent post.
after this commit, closing fields will be shown only
once post is closed and parent_id and is_correct
field will be shown only in child post(answer)
closesodoo/odoo#129299
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
before this commit, in the forum validation queue filter,
along with the text filter instead of icon some hard coded
value(圾) is shown as text.
* create a user with very minimum XP
* create a post from new user login
* from admin login, click validation queue in the
forum
* click on filter in the validation queue
after this commit, the text will be replaced with fa-font
icon, so that all filters will look similar.
closesodoo/odoo#123636
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Information about iap services and current credit available to view from odoo
Can edit some iap services fields from odoo (warn me, warn threshold and warn email)
Change the redirect route of view services to view my IAP accounts
Add button to buy credits from the form view of iap accounts
closesodoo/odoo#121398
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
before this commit, on deleting a question from
forum is redirecting to the same question
page with deleted tag.
after this commit, user will be redirected to
forum home page after deleting a question
closesodoo/odoo#118686
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*: bus, calendar, im_livechat, web, website_livechat.
This PR adds the possibility to set the current user during tests as
well as the mail guest. This will be used to test mail guest page and
livechat once the visitors will be treated as guests.
part of task-3332628
closesodoo/odoo#130811
Related: odoo/enterprise#45331
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
With the introduction of Bootstrap in the PoS, the navbar was still
accessible when showing a tempScreen as the PartnerListScreen. This is
not intended as the tempScreen act "like a big popup" where the user
must do the action on the tempScreen before doing anything else.
The problem here is that the Bootstrap integretion forgot to add the
correct style to the div "block-top-header" which is done in this PR
(background-color, width, height and position).
closesodoo/odoo#130736
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Since [1] form fields cannot be moved outside of their form and since
[2] table of contents cannot be nested within another table of content.
Those were implemented with specific references to website classes
within web_editor.
This commit introduces declarative mechanisms for both situations:
- `data-drop-lock-within`: prevents dropping outside the closest parent
that matches the specified selector.
- `data-drop-exclude-ancestor`: disallows dropping within a parent that
matches the specified selector.
[1]: https://github.com/odoo/odoo/commit/638d0e875dcb05191fe833d2f889235891dfb46a
[2]: https://github.com/odoo/odoo/commit/55339cd6a7b7916184893c0fe27b5483683a047a
task-3131384
closesodoo/odoo#130477
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
This PR adds the `add_guest_to_context` decorator in order to provide a generic
way to extract the guest from a request. It will be used to unified guest
extraction from cookie/param based on its provenance (external livechat/public
page).
This is better than the `pre_dispatch` method since it can be applied to
specific routes instead of adding this logic to every request.
part of task-3332628
closesodoo/odoo#130052
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
With this commit, users can send voice messages in channels and chat.
There's a new button in composer to record audio from the microphone,
up to 1 minute clip duration. This adds a voice attachment with its
dedicated voice player that shows waveforms and allows playback.
To ensure compatibility in all supported browsers, we choose to
encode voice recording with `audio/mp3` thanks to lib `lamejs`.
Task-3240168
closesodoo/odoo#117036
Related: odoo/enterprise#45482
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When the payment method was detached from the customer, trying to pay with the
linked payment token would end up with a crash because Stripe failed to send us
the payment intent, as it could not create it. In that case, a logger error
occurs on the server which creates noise in the sentry.
Error: The creation of the payment intent failed.
Stripe gave us the following info about the problem:
'Your card has insufficient funds.'
The logger is updated to use the 'warning' level instead of the 'error' level.
This change reflects a less severe logging level for cases where the creation
of payment intent fails.
sentry-4363481906
closesodoo/odoo#131334
X-original-commit: 772457554083847eb6088509ed57acff86702783
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Saurabh Choraria (sauc) <sauc@odoo.com>
When a customer requests an invoice in the `point_of_sale`, use the same
flow as in `account`: the "Send & Print" button.
It generates the pdf, the EDI attachments (Factur-X, Peppol Bis 3, etc)
and send it to the customers/governement. Indeed, in some countries, it
is required to sign the invoice to the government upon validation (e.g.
CFDI in Mexico).
closesodoo/odoo#131317
X-original-commit: 2cc9a35860b59063f536eea9234a1e9c5fa2f00e
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Since the use of Bootstrap, the money inputs using the useValidateCashInput hook are no longer correctly displayed when the user input is invalid.
Steps to reproduce:
- Open a session in a shop
- Open the "Cash In/Out" menu with the top right dropdown menu
- Enter an invalid amount, like "invalid" for example
The input is not displayed with red borders.
This commit fixes the display of invalid inputs in the Cash In/Out and Closing Session popups, using the Bootstrap is-invalid CSS class.
closesodoo/odoo#131246
Task-id: 3444048
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Since 16.4, the number of file made pylint reach the default memory
limit from time to time. This commit will remove the limit for this test
as it was done for chrome. The next step would be to split the test
per set of module or maybe analyze the memory consuption of some custom
check.
closesodoo/odoo#131336
X-original-commit: 8acb8d9a8bf5e19b53528275a4ddd5d4a289472b
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Steps to reproduce:
- Go to Contacts and open any contact (e.g. Contact X)
- Check its configured Account Receivable (e.g. 121000 Account Receivable)
- Configure that account and set a default Sales tax on it (e.g. Tax 15%)
- Create an invoice with Contact X as customer
- Add an invoice line for any amount (e.g. $100) and any tax
- Swith to "Journal Items" tab and display "Taxes" column
A line (with 121000 Account Receivable) has been created automatically to balance the invoice line.
This line has a tax (i.e. Tax 15%): the default one configured on the account.
There should not be a tax for a receivable account.
Another issue is that the tax is set on the aml but not tax line has been created.
- Go back to "Invoice Lines" tab
- Remove the tax on the invoice line
- Save
In "Journal Items" tab, the tax line has been created from the aml with the receivable account.
- Go back to "Invoice Lines" tab
- Add a tax on the invoice line again
- Save
- Remove the tax on the invoice line
- Save
In "Journal Items" tab, there are now 2 tax lines from the aml with the receivable account.
By repeating the previous steps, new tax lines can be created infinitely.
Solution:
To prevent the issue, the default taxes shouldn't be populated on the aml when the account
is a receivable (or payable) one and when the move type is an "invoice" type one.
As "display_type" field of "account.move.line" is set to "payment_term" when the account is
a receivable or a payable one and when "is_invoice" is True on the move, no tax will be set
in "_compute_tax_ids" computed method when "display_type" is "payment_term".
opw-3345953
closesodoo/odoo#131330
X-original-commit: c6076a272cfe997856f3026557900ce9718c45e5
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
`_get_starred_counter` method is obsolete now.
So, there is no meaning in keeping it anymore.
It's usecase has been removed by this PR
https://github.com/odoo/odoo/pull/83777closesodoo/odoo#131299
X-original-commit: cbf590bfa0999e99064e1a2bb337c8e63f00dd8c
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Rahul Prajapati (rapr) <rapr@odoo.com>
Incorporate Alejandro Mellado (alejandromellado) as Vauxoo's contributor.
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#131277
X-original-commit: 73ee076bb20245fde8629a9f16caea16424c105b
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Steps to reproduce this bug:
1- On a Bank type journal, set true the "Use electronic and deferred
checks" field
2- Do a new vendor payment with Bank journal and Manual payment method
3- Corresponding journal entry shows "Check False delivered"
closesodoo/odoo#131256
X-original-commit: 4f70fb08af830dd2fece740905c02e598a26b0f6
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Reproduction:
1. Install Note, create a new note
2. Start the Inspector, edit the placeholder <p> element in the
description
3. Replace the element as `<p style="color: rgb(32, 31, 30); font-family
: "Segoe UI", "Segoe UI Web (West European)", "
Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helveti
ca Neue", sans-serif; font-size: 15px;">dsfhislahflidsahisa</p>`
4. The saving icon appears, click it but it will always be there, e.g.
always dirty
Fix: instead of comparing the raw value of the prop value and editing
value, we parse them and compare after the parsing
opw-3341605
task-3434080
closesodoo/odoo#131245
X-original-commit: eda483bd3c3bdc42b95f17a5278c1a9eb83adb05
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Jinjiu Liu (jili) <jili@odoo.com>
Similar to what was done [here](https://github.com/odoo/odoo/commit/5d0111d079601c07c62717575cb22ead15c585d0) when the credit limit feature
was introduced, a `sudo()` is also necessary in
`_load_records_create()`.
This method is called when importing contacts from a CSV file.
So the access to the commercial fields is done when synching
fields from the commercial entity to its contact and should
not block the import.
Fixes#126567closesodoo/odoo#131225
X-original-commit: 266e22fc4ea5bb4343700f8d08f9ec2580fab365
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Before this commit, the follower loading spinner was shown
for draft records until it was saved. This is incorrect,
follower count should instead be 0. This commit fixes this
issue.
closesodoo/odoo#131224
Signed-off-by: Didier Debondt (did) <did@odoo.com>
To reproduce the issue, follow these steps:
1. Install the Timesheet and Project.
2. From the settings menu, create a new company.
3. Create a project using the newly created company(e.g. New Company) and add
a task to it.
4. Open the Timesheet application and create a new timesheet.
5. In the timesheet, select the project created in step 3, and observe that the
dropdown for tasks does not display any task.
Cause for this issue:
-The timesheet application has a domain set for the task field where the company
associated with the task_id should be the same as the company selected in the
current environment.
-However, when a new project is created with a 'New Company', the tasks
associated with it also have the 'New Company' assigned to them. On the other
hand, the current environment has a default company called 'Your Company'
associated with it.
-Therefore, due to this domain setting, the task field does
not display any tasks since there are no tasks associated with the
'Your Company' in the current environment.
Fix:
Since the cause of the issue is related to the company domain set in the task
field, we can solve it by removing it from the domain.
task-3323027
closesodoo/odoo#131197
X-original-commit: 7b9f9a1323ecaeab2b248784e1493b39fe07b8f1
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The 'onsite' payment provider shouldn't be shown to the user
if the cart/order only contains services (or if there are no onsite carriers).
The logic was there but the filtering didn't correctly update the values.
opw-3437107
closesodoo/odoo#131177
X-original-commit: 78cd9a7ab5fb860021a906400a1907b1d8b45be2
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, calls to record[fieldname][value/raw_value] in
the arch of a kanban view did not take into account updates on the Record
Datapoint. So if any data in the Record changed, the [raw_value/value]
was not modified.
In a custom KanbanRecord, you should never use the record containing the
value and raw_value. We will therefore replace this call by using the
datapoint record directly.
How to reproduce:
- Have a kanban view with a record.my_field.value and a widget allowing
you to modify the value of my_field.
- Click on the widget
Before this commit:
The value of my_field does not change
After this commit:
The value of my_field has been updated.
closesodoo/odoo#131165
Related: odoo/enterprise#45413
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Nicolas Bayet