Some modals (`.o_error_dialog`) have a visual bug and goes outside the
viewport. This bug occurs because the CSS `top` attribute is override by
an inline style.
The result CSS is
```css
.o_error_dialog {
top: 50%; /* Ignored due to the inline top rule */
transform: translateY(-50%);
top: 0; /* Override inline style */
}
```
The commit instead use the Bootstrap 5.1 class `modal-dialog-centered`
to center vertically the modal.
Note: from now all modal will be center vertically as it's the direction
of the future design.
Steps to reproduce:
* Go to `Bank Accounts` menu
* Create a new recode (New button)
* Enter a `Account Number` and select an `Account Holder`
* Then check `Send Money`
* Try to save (cloud icon) => BUG the modal is outside the viewport
closesodoo/odoo#114535
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This PR change the delete button in the attendee calendar if the
event is recurrent.
If the event is recurrent, a wizard pop up to ask if you
wish to remove :
- The selected event
- The selected event and the following
- All the event in the recurrence
task-id : 3148011
closesodoo/odoo#113024
Signed-off-by: Arnaud Joset <arj@odoo.com>
The logic to display the payment status of invoice(s) has been quite
messy for a long time, leading to a lot of confusion and some bugfixes.
This commit tries to simplify and harmonize the logic, and to provide
a clear logic and ordering of the payment states, following
1) the invoice state (cancelled state)
2) the accounting state (related to `account.payment` records and logic)
3) the payment state (related to `payment.transaction` records, holding
states not reflected in accounting logic until effectively confirmed).
closesodoo/odoo#111046
Related: odoo/upgrade#4409
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The module ´account_payment_invoice_online_payment_patch´ was added in stable to allow
account_payment users to disable online invoice payment
(without removing the module, critical for other flows).
It can be safely merged into the account_payment module for future versions.
Original bugfix PR: #110177
Related to opw-3114860
Part-of: odoo/odoo#111046
CONTEXT
Followup of odoo/odoo@2d791e8afe (posting, notifying and composer / template link code
cleaning) and odoo/odoo@0b8d4c0eb1 (composer fields, template sync and values generation
cleaning).
RATIONALE
Naming conventions
* content = core message / subject (+ other fields);
* email layout = layouting applied to messages when sent to recipients who
receive notifications by email e.g. access button, ...;
* comment mode / mailing mode: composer main composition mode: posting on
record(s) / sending a mailing on records;
Content situation when using a template on the composer
* comment, monorecord mode: choose a template, content is rendered directly
from template side according to 'lang' field definition -> ok;
* comment, multirecord mode / mailing mode: choose a template, content is
the raw content. At post / send, content is rendered on composer side.
As composer is not translated -> no translation -> ko;
Email layout situation when posting / mailing
* comment, monorecord model, using a template from UX: layout is partly
translated based on template 'lang' field to match the content translation.
Part of the layout still uses the current user lang;
* other comment use cases: layout is translated based on current user;
* mailing mode: layout not supported;
EXPECTED SITUATION
Content situation when using a template to post on a composer
* comment, monorecord mode: choose a template, content is rendered directly
from template side according to 'lang' field definition -> ok;
* comment, multirecord mode / mailing mode: choose a template, content is
the raw content. At post / send, content is rendered and translated if
matching template content -> ok;
Email layout situation when posting / mailing
* comment: layout translated based on recipient lang or fallback on template
'lang' field definition, or current user's lang;
* mailing: support layout through composer, use template 'lang' field definition
or fallback on current user's lang;
For more details, see sub commits with their detailed explanations.
LINKS
Task-3046371 (Mail: Better Language Support in Composer)
Task-2742033 (Mail: Use recipient lang in template contextual action)
Task-2555155 (Mail: Translate notification action/access buttons)
Task-3186426 (Mail: Support notification layout in template / email composer)
closesodoo/odoo#106177
Related: odoo/enterprise#37296
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
RATIONALE
Naming conventions
* content = core message / subject (+ other fields);
* email layout = layouting applied to messages when sent to recipients who
receive notifications by email e.g. access button, ...;
* comment mode / mailing mode: composer main composition mode: posting on
record(s) / sending a mailing on records;
Content situation when using a template to post on a composer
* comment, monorecord mode: choose a template, content is rendered directly
from template side according to 'lang' field definition -> ok;
* comment, multirecord mode / mailing mode: choose a template, content is
the raw content. At post / send, content is rendered and translated if
matching template content -> ok;
Email layout situation when posting / mailing
* comment: layout translated based on recipient lang or fallback on template
'lang' field definition, or current user's lang;
* mailing: no layout supported;
PURPOSE
Make those the two composer modes less different by supporting layouting in
mailing mode of composer. Consider it a bit experimental.
SPECIFICATIONS
When using the composer in mailing mode, render email layout if given. This
layout is used to encapsulate body.
To simplify rendering and sending, consider all recipients to be 'customer'
as defined in '_notify_get_recipients'. This means all recipients receive the
same basic layouting currently as a first attempt to improve this situation.
Considered lang is the one coming from the template 'lang' field, or fallback
on current user's lang.
Task-3186426 (Mail: Support notification layout in template / email composer)
Part-of: odoo/odoo#106177
RATIONALE
Naming conventions
* content = core message / subject (+ other fields);
* email layout = layouting applied to messages when sent to recipients who
receive notifications by email e.g. access button, ...;
* comment mode / mailing mode: composer main composition mode: posting on
record(s) / sending a mailing on records;
Content situation when using a template to post on a composer
* comment, monorecord mode: choose a template, content is rendered directly
from template side according to 'lang' field definition -> ok;
* comment, multirecord mode / mailing mode: choose a template, content is
the raw content. At post / send, content is rendered and translated if
matching template content -> ok;
Email layout situation when posting / mailing
* comment: layout translated based on template 'lang' field definition
or fallback on current user's lang;
* mailing: no layout supported;
PURPOSE
Translate layout into recipient's lang when available, instead of either
current user or template defined lang. As it is contextual better translate
it to the end user lang.
SPECIFICATIONS
Move recipients and email layout rendering into a method returning an iterator.
That way a list of recipient groups (as given by '_notify_get_recipients') can
be split into sub-groups, with each having its own rendering values for
email notifications.
Do a split / recipient lang. It is already fetched when notifying messages
as part of '_get_recipient_data' returned values. We now return recipients
groups per lang and per usage type (user, portal, customer, ...). Rendering
values are computed for each group as several values depend on the lang (
actions, notification buttons, global layout, ...).
Layouts when posting are dependent on recipient lang, and not on current user
anymore. Template lang that forced the content lang is now used only as a
fallback when recipient have no lang.
SUMMARY
When a user in Spanish, posts using a template specifying the lang of the
customer on a record whose customer is in French, with a follower being
in English
* content will be translated following template choice, aka french;
* layouting for the french customer will be in french, layouting for the
english customer is in english, while the core content is always the
same and in french;
When a user in Spanish, posts some custome content on a record whose customer
is in French, with a follower being in English
* content is whatever the user wrote;
* layouting for the french customer will be in french, layouting for the
english customer is in english, while the core content is always the
same and in french;
Task-3046371 (Mail: Better Language Support in Composer)
Task-2555155 (Mail: Translate notification action/access buttons)
Task-3186426 (Mail: Support notification layout in template / email composer)
Part-of: odoo/odoo#106177
Co-authored-by: Julien Banken <jbn@odoo.com>
RATIONALE
Naming conventions
* content = core message / subject (+ other fields);
* email layout = layouting applied to messages when sent to recipients who
receive notifications by email e.g. access button, ...;
* comment mode / mailing mode: composer main composition mode: posting on
record(s) / sending a mailing on records;
Content situation when using a template to post on a composer
* comment, monorecord mode: choose a template, content is rendered directly
from template side according to 'lang' field definition -> ok;
* comment, multirecord mode / mailing mode: choose a template, content is
the raw content. At post / send, content is rendered and translated if
matching template content -> ok;
Email layout situation when posting / mailing
* comment, monorecord model, using a template from UX: layout is partly
translated based on template 'lang' field to match the content translation.
Part of the layout still uses the current user lang;
* other comment use cases: layout is translated based on current user lang;
* mailing mode: layout not supported;
PURPOSE
Correctly propagate lang from template in all situations whenever a template
is used, and translate all layout parts.
SPECIFICATIONS
When using the composer to post messages (either as comment or in batch) the
language coming from the template is not propagated until the notification
process.
A hack has been done to try to guess the language inside the notification
process, based on context keys at odoo/odoo@9e71d228ed. This was done to partly fix
the bug in stable.
Since odoo/odoo@3eb9680602 it is possible to propagate a lang from 'message_post' or
'message_notify' calls until the notification process. We can therefore call
the posting methods using the rendered lang (in both mono and multi record
modes) and remove that hack.
When a lang is propagated using the 'force_email_lang' it is used to choose
the language of the layout (content, buttons). Currently all recipients
receives the same language for layouting. We plan to soon use the recipient
language when possible, then fallback on that forced lang. This will offer
more granularity and a better user experience.
When using scheduled messages (creating message but delaying the sending of
notifications) it is also working as notification parameters are saved when
creating the scheduling record, see odoo/odoo@9b11a9d82b.
EXAMPLE
A user in english uses a template on a lead whose customer is in spanish
with a follower being in german. Template lang is customer's lang:
* content is translated into spanish (customer's lang);
* layout is translated into spanish (customer's lang);
Both recipients (customer and follower) receive the content in spanish.
LINKS
Task-3046371 (Mail: Better Language Support in Composer)
Task-2555155 (Mail: Translate notification action/access buttons)
Part-of: odoo/odoo#106177
RATIONALE
Naming conventions
* content = core message / subject (+ other fields);
* email layout = layouting applied to messages when sent to recipients who
receive notifications by email e.g. access button, ...;
* comment mode / mailing mode: composer main composition mode: posting on
record(s) / sending a mailing on records;
Content situation when using a template on the composer
* comment, monorecord mode: choose a template, content is rendered directly
from template side according to 'lang' field definition -> ok;
* comment, multirecord mode / mailing mode: choose a template, content is
the raw content. At post / send, content is rendered on composer side.
As composer is not translated -> no translation -> ko;
PURPOSE
Take translations from template when composer content is the same as the
template one to benefits from their translations.
SPECIFICATIONS
When rendering some fields fetching translations can be complicated. Indeed
when using a template the translation is stored on template model while the
rendering is done on composer model. Translations are therefore not fetched
as fields of the composer record itself are not translated. It is a transient
record, not something people translate manually like templates.
As translations are not stored in a table anymore we can't really fetch
translations, except from using directly the template field. In this commit
we therefore do the rendering based on template value instead of composer
value when they are considered as equal and if a translation is asked either
through 'compute_lang' of 'force_lang'. This allows to fetch template
translations instead of composer translations.
If the composer content has been modified compared to the template we keep
the old behavior, which means probably no translations. Let us hope editor
does not mess too much with html content.
EXAMPLE
A user in english uses a template on a lead whose customer is in spanish
with a follower being in german. Template lang is customer's lang:
* content is translated into spanish (customer's lang);
Concerning layout (to be fixed in next commits):
* layout is partly translated into spanish (customer's lang) if coming from
form view, otherwise is in english (current user's lang);
LINKS
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#106177
When rendering content, options can be given to trigger some behavior
like post processing (links shortening) or comments to preserve in html
(for email reader specific commands).
In this commit we make an allowed list of options. This eases debugging
or finding wrong calls, outdated options, ...
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#106177
Purpose of this commit is to improve behavior or mail.compose.mixin when
removing the template. It now voids the value to avoid having half baked
definition on composers.
Summary of behavior
* when choosing a template: existing (non void) values override any value
in the composer mixin;
* when removing a template: reset values;
* when going from templateA to templateB: works like choosing a template
which means only non void values are taken. This may lead to half-baked
content but trying to remove old template content based on _origin and
content comparisons would be complicated for few added value;
This makes the 'mail.compose.mixin' behaves like 'mail.compose.message'
wizard which was recently updated at odoo/odoo#107356.
Task-3093257 (Mail: The Composer Update)
Part-of: odoo/odoo#106177
RATIONALE
Purpose of this commit is to add helper field knowing if body any model
inheriting from the 'mail.composer.mixin' is synchronized with their
template value.
SPECIFICATIONS
Add a field to check if body of a composer is the same as its template
* compare both current (raw) values and sanitized values, as sanitization
process may change some bits of html code;
* correctly check for void content using the tool;
Obviously this may be broken if editor usage changes the source template value
DOM when saving it in the composer. However we can't do much more than using
the original and sanitized values from template and compare them with the
current composer values.
It is used in this commit to simplify a bit code in '_render_field' override.
It is used to detect any change in body based on template. It highlights
potential changes in QWeb directives which requires usage of editor group.
This method is also cleaned in order to have less calls to super() in nested
if-elif structures. As some additional code will be added soon it is better
to have a simpler code flow.
Finally add some tests about current state of fields synchronization notably
when setting a template with void values, or removing the template.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#106177
Mail composer mixin already synchronizes subject and body based on a mail
template, easing calling rendering methods available through mail render
mixin.
In this commit we add the same mechanism on lang. Lang is taken from the
template and can be used to render content based on language defined on
template, generally based on a customer.
Some query counters are updated, without being sure those are really coming
from this commit. Anyway they will be updated in batch at the end of this
PR, as tracking them on each commit is tedious and not always really
useful.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#106177
This commit contains mainly code cleaning, docstrings and a small split
for notification tool methods. In this commit we
* make some notification groups variable explicit;
* move the filler of groups into its own submethod to ease being called
from other code (to be used soon);
* fix some strange overrides or code manipulation;
* propagate some additional parameters to ease future commits that will
improve rendering of groups-based notification emails;
* cleanup, fixup and improve docstrings;
This does not change anything from functional point of view, just preparing
further work.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#106177
In order to prevent sms spamming the responsible of events, for users
having a lot of calendar events, like hairdressers (through appointment),
we add a field on the calendar.alarm model to make the sms reminder
optional. As not reminding the responsible is meant as a default
behavior, sms_notify_responsible is False by default.
This field is only meant for sms alarm_type. Indeed, by default, email
are not issued to their author and if the responsible is set in the
calendar_event, it will be used as author. Notifications are not
concerned by this issue as we consider we want to always receive the
internal reminder.
In order to distinguish between sms alarms with or without responsible
reminder, we add " - Notify Responsible " to the sms calendar alarms
with the option set to True. (This is also useful when alarms are used
in a m2m, like for appointment types or calendar events.)
Task-3032570
closesodoo/odoo#104327
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This commit adds a new mail template to be sent by default for interviews.
task-2884526
closesodoo/odoo#94178
Related: odoo/upgrade#3731
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps to reproduce:
- create an attribute with "never" as the mode of creation;
- create a product with this attribute;
- add an optional products to this product;
- go to ecommerce and add this product to the cart;
- take care to change the value of the attribute;
- click on the "Proceed to Checkout" button.
Note: optional product allows to open the modal window on the ecommerce
Issue:
In the cart, the selected attributes are the default ones.
Cause:
We will look for the information in the modal window template.
Unfortunately, the `getCustomVariantValues` and `getNoVariantAttributeValues`
functions are not adapted to the modal window template.
Therefore, the information is not found.
Solution:
As the information is searched on the template of the modal window,
it is necessary to maintain the information on it.
opw-3140859
closesodoo/odoo#114753
X-original-commit: cc0bcb15ec88dd67fd9225c6decc3451b4df4708
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Follow up of https://github.com/odoo/odoo/pull/90415
After removing the public field, the equivalent access is to set the
allowed group to empty.
closesodoo/odoo#114729
X-original-commit: fcafd602dda4f896ac8b91c81c00ee723afd6634
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, updating a purchase quantity of subcontracting
product will try to not merge the new and old move to keep the two chain
separated as much is possible and avoid side effects (receipt move,
subcontracting moves, resupply moves). Some were merged, some cancelled,
...
This had two issues:
First, not merging the quantity was not guarantied
as you can specify you don't want to merge them with others but it's not
possible for a stock move to say to any other move do not merge with me.
Second, by not merging the receipt moves, we duplicate every other
object on the chain. This pollute the database uselessly.
opw-3147446
closesodoo/odoo#114739
X-original-commit: 0b1bcfacb13c7de480f30015b91db11ed03f2dfe
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before commit:
There was no mobile field in the optional fields of tree view in res.partner.
After commit:
Added the mobile field as optional field.
Task-3184771
closesodoo/odoo#113243
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
PURPOSE
After internal feedback, improve crm activity reporting and lead duplicates
finding by tweaking the feature and adding indexes.
SPECIFICATIONS
[PERF] crm: add index on phone_sanitized
This allows to speedup exact match searching, notably in lead duplicates.
[PERF] crm: rewrite duplicates computation
Criterions are now
* email domain exact match;
* phone_sanitized exact match;
* same commercial entity;
[PERF] mail: update index on mail_activity_type_id
Only not null values matter.
[PERF] crm: fix performances of activity report
Remove inclusion of discussion messages in the query. Keep only activities-based
messages.
See sub commits for more detailed rationales.
Task-3129356 (Crm: Fix activity report performances)
Task-3142659 (Crm: Fix duplicate leads computation performances)
closesodoo/odoo#112535
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
RATIONALE
Activity report is slow, as it makes a complex query inside mail.message table
which is one of our biggest table with crm.lead table, also a big table. This
activity report could be speeduped by looking only on activities, not including
discussions messages.
SOLUTION
Rationale is that discussions can be about whatever (real discussion with
customers but also internal discussion, notes, ...). What matter here is to
report on activities like phonecalls, followup emails, meetings, ... to have
a global view of sales people activity.
SPECIFICATIONS
Remove inclusion of discussion messages in the query. Keep only activities-based
messages.
Task-3129356 (Crm: Fix activity report performances)
Part-of: odoo/odoo#112535
RATIONALE
Activity report is slow, as it makes a complex query inside mail.message table
which is one of our biggest table with crm.lead table, also a big table. This
activity report could be speeduped by looking only on activities, not including
discussions messages.
SPECIFICATIONS
Index on "mail_activity_type_id" field of <mail.message> is updated as main
searches include a not null on mail activity type id field.
Task-3129356 (Crm: Fix activity report performances)
Part-of: odoo/odoo#112535
RATIONALE
Duplicates computation on leads is slow when having a lot of leads. We can
simplify the heuristic to keep only relevant terms and use tailored fields
to find duplicates based on email and phone, to speedup the computation while
loosing few duplicates or avoiding false duplicates.
SPECIFICATIONS
We remove
* an ilike on email_normalized (slow and exact matches are what really
matters);
* an ilike based on partner_name and contact_name (as lead is a contact
oriented record, better optimize email and phone / mobile than names that
are weak criterions);
* an ilike on phone_mobile_search, which was searching on both fields
phone and mobile;
Criterions are now
* email domain exact match;
* phone_sanitized exact match;
* same commercial entity;
Main change is that only phone_sanitized is used for exact match. Partial
matching based on phone and mobile number is lost. That should not be an
issue as real duplicates should come with a complete phone or mobile number
and not partial numbers. First found in phone / mobile populates the phone
sanitized field, meaning if we have two different numbers, only one is used
for duplicate finding. This is considered acceptable.
Other main change is the removal of partner name / contact name search. Those
are weak criterions and did not return any explicit result when used internally.
Task-3142659 (Crm: Fix duplicate leads computation performances)
Part-of: odoo/odoo#112535
RATIONALE
Duplicates computation on leads is slow when having a lot of leads. We can
simplify the heuristic to keep only relevant terms and use tailored fields
to find duplicates based on email and phone, to speedup the computation while
loosing few duplicates or avoiding false duplicates.
SPECIFICATIONS
Index on "phone_sanitized" field of <crm.lead> is added as btree_not_null as
it is mainly used to search for direct matches. Partial searches are not the
main usage of this field.
Task-3142659 (Crm: Fix duplicate leads computation performances)
Part-of: odoo/odoo#112535
Before this commit, it was not possible to partially capture a
transaction from Odoo, and doing so in the provider backend would often
result in a full capture in Odoo when capture was supported.
With this commit, partial captures are made available in Odoo directly
from the sales order or invoice, for providers that support them.
Provider can either only support full capture or also support partial
ones. It also optionally managed the automatic void of the remaining
amount at the user request when multiple captures are supported by the
provider.
As of now, the only acquirer allowing partial capture is Adyen.
task-2728768
closesodoo/odoo#87251
Related: odoo/enterprise#35205
Related: odoo/documentation#2063
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit:
unable to remove blockquote and heading element if first element.
After this commit:
removed element on backspace even if first element.
Task- 3004556
closesodoo/odoo#114727
X-original-commit: f0bbf1aab823524a74a52f694c0564dd23618a90
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Purpose
=======
In addition to the current alert message, when a user
forgot to pick an answer in a matrix, highlight in red
the rows where the answer is missing.
Task-3162051
closesodoo/odoo#111715
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The TriggerTree class does not have a specific __repr__(). It thus
falls back on dict's __repr__(), which does not show the root of the
tree. This makes debugging hard and confusing.
closesodoo/odoo#113521
Signed-off-by: Raphael Collet <rco@odoo.com>
Before this PR the task state was fixed by the kanban_state field which was useful when you use the stage of the project as parts of a pipeline,
but not relevant when users are using stages as bucket lists. (specific examples at the end of the specs)
The goal of this PR is to provide users a way to mark their tasks as done with a simple button press,
while keeping the option to label a task as Approved, Canceled or Requesting changes like in the old kanban_state field.
The kanban_state of a task had no impact whatsoever on other tasks of the pipe, we would like to change that and make the task state have an influence on its dependent tasks.
The state will also have influence over the 'recurrent' tasks (to be implemented in Task #3084945)
If you want a better description of those changes with screenshot and colors check specs of:
Task-3084930
PRs:
See odoo/enterprise#35359
See odoo/upgrade#4367
-----------------------------------------
Interaction with blocking tasks:
the closed values which mark the task as closed or finished:
- Done
- Canceled
The Open values when the task isn't finished yet:
- In progress
- Changes Requested
- Approved
- Waiting (which is not selectable)
Where to change the state of a task:
- For kanban and form views: same place as kanban_state (bottom right of kanban card, top right of form view)
- For list view: left of list (after task priority)
more details about the state widget in state field widgets part
Interaction with existing fields
- is_closed: which was determined by the task.stage_id.fold, now a task is closed when in one of the following stages
- Done
- Canceled
a closed task is considered as finished, the time of the closing will be stored in the date_last_stage_update field
- is_blocked: a task is considered blocked if ANY of its blocking task is in one of the blocking states (more details about this in the following part Interaction with blocking tasks):
- in Progress
- Changes Requested
- Approved
- Waiting
!! important !! is_closed and is_blocked are not mutually exclusive, you can have a task that blocked and is closed at the same time, the reason why will be explained late
date_last_stage_update: this field is updated everytime the task goes into a closing state OR when the task changes stage.
We need to check that the value is updated in each case (using the already available filter)
Interaction with blocking tasks
the state of a task can now be changed by its blocking tasks following the logic:
if ANY of the blocking tasks is NOT closed (so its state is in one of the open values) the task is considered as blocked
- if a task is blocked and NOT closed its state will switch to Waiting
- the Waiting state will display an unclickable hourglass icon on the task kanban/list views, once in the waiting state you can't change the state of the taskfrom the kanban/list views
- a blocked task state can be changed through the form view, so you can override the 'block' by choosing a closed state (only done or canceled)
- once overriden, the task will change to the closed state the user wants, but the task is still blocked so in case where the user comes back to an open state, the task will automatically switch back to the waiting state (according to the state before the block)
- if the blocking task switches to a non-blocking state, the task will not be considered as blocked anymore and its state will switch back to In Progress
Default values
the default value is always in progress
Special cases
when a task is moved from a stage to another one
- if the state was in one of the open states (approved, changes requested, in progress ) the state goes back to In Progress
- if not, the state stays the same
when a task is moved from a project to another one
- the state goes back to In Progress
when a task is duplicated
- if the state was in one of the open states (approved, changes requested, in progress ) the state goes back to In Progress
- if not, the state stays the same
closesodoo/odoo#107593
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In Settings>Accounting set 'Sales Credit Limit' to 10,000
Create a user with sales access but no accounting rights
Login with the sale user, create a quotation, set a partner
already exceeding the limit
No warning shows up.
This occurs because the field is restricted to users having account
access
opw-3202384
closesodoo/odoo#114685
X-original-commit: 317977e97d93f572697585d006b5bca5c7365428
Signed-off-by: John Laterre (jol) <jol@odoo.com>
This commit transforms the OdooEditor test utils file into an
odoo-module and makes it available for importing in QUnit tests.
closesodoo/odoo#114643
X-original-commit: df2125b7ce50031f0de8f5d78536d50e6c688dd1
Related: odoo/enterprise#37896
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The type fields of actions already defaults to
the model name in the base model definition.
Therefore, specifying `ir.actions.server`, `ir.actions.act_window`
& so on as type is useless (and adds noise since it's the same as
the action model).
closesodoo/odoo#114539
Related: odoo/enterprise#37855
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Steps to reproduce:
-Go to calendar
-Change the view to see the whole month.
-Watch every meeting we have.
Issue:
We are missing the starting hour for the meetings that we had working on
previous versions.
Solution:
Added proper way to display the hour to the
`calendar.AttendeeCalendarCommonRenderer.event` template.
opw-3119858
closesodoo/odoo#114251
X-original-commit: 90020976ab2a0e6a35ab4624ff227c30edc8d249
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Maruan Aguerdouh Mohtar (magm) <magm@odoo.com>
Removed since user can achieve good enough results using border
and round corner options.
IMPORTANT: the option could be removed from image wall only (and
not from image gallery) using "data-dependencies=slideshow_mode_opt"
(since they use the same code), but it's removed from both "for now".
task-2692129
closesodoo/odoo#81959
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Bootstrap tables can basically be customized with the `$table-bg` and
`$table-color` variables. The problem is that, by default, BS4 defines
them so that the background-color is null (so transparent: displaying
the background-color of its ancestors) but the color is forced to the
body color (by default: white). This is a problem as soon as the
ancestors background colors are a color close to the body text color:
the text becomes invisible. For instance, in website:
- Set a body background color to black, the body text will automatically
become white.
- Add a table in a snippet: still ok, the text in the table is white
over the black body (the table being transparent).
- Then set the snippet background to white -> the table text will still
be white... but now over a white background.
This should be reviewed in master: it should be ok to set the variable
$table-color to `null` thus letting the table be transparent and have
the same text color as its parent. But in stable, changing a color
variable to `null` could break customizations relying on the fact this
is a set color. It would also not make sense if the user set up a
`$table-bg` value going well with table text forced to the body color.
Instead, here, in the very specific case we have a transparent table bg
and table color equal to the body color, we temporarily unset the table
color variable for the duration of the bootstrap table rules.
Note: we cannot create a rule in an "Odoo file" to fix this as unsetting
the color for the `.table` rule would also unset the color in the case
of a `.table.bg-XXX` where we still want `.bg-XXX` to force the color.
task-2728923
opw-3048306
opw-3180568
closesodoo/odoo#114631
X-original-commit: 02c2cfdff7c29252c7036e587b12d82442906e59
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce the bug:
- Go to decimal accuracy > product unit of measure
- Change the Digits from 2 to 4
- Create a storable product “P1”:
- Create a BoM:
- Add 1 unit of a component
- Create a MO:
- Product : P1
- Qty to produce: 41,0654
- Confirm the MO
- click on Action and try to split the MO in two:
- MO_1: qty 35,9757
- MO_2: qty 5,0897
- Validate the split
Problem:
A user error is triggered, “Unable to split with more than the quantity
to produce.”
While (35,9757 + 5,0897) = 41,0654
we have to use `float_compare` to avoid this kind of error
opw-3178441
closesodoo/odoo#114672
X-original-commit: dbaf8da533f4587f5ca9b0b82bea46488ba6e05a
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
First issue: post a credit note
Steps to reproduce:
- enable anglo-saxon accounting and storno
- create a storable product with sale price = 50 and cost = 30
- set costing method FIFO and automated inventory valuation on product category
- create a credit note using this product
- post credit note
Error:
There was a problem with the following move(s):
- Move with id 18
The debit and credit should be negative and only one can be set
Second issue: return a product
In anglo-saxon accounting, returning a product means creating a reverse move.
Reverse move in storno should have a negative debit/credit.
opw-3110934
closesodoo/odoo#114671
X-original-commit: f24a87b1d0bb3a18ef1d2d4cd23fb34bf29d4bfb
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
before this commit, even if the tax description is set in the tax, in the repair report it always displays the tax name.
after this commit, as in the sales, purchase and invoice reports, if tax description is set, repair order will display the tax description in the report.
closesodoo/odoo#114670
X-original-commit: e9ba4ae9608f6139d3fb1633d0e3287cb7348cb7
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
before this commit, enabling the mass editing for the picking operation type tree view or for purchase.order tree view using the studio, throws the exception.
* install studio
* open purchase order tree
* enable mass editing for the tree from studio app
* exception will be shown
after this commit, on enabling mass editing on this tree view, will not throw exception.
closesodoo/odoo#114669
X-original-commit: dad9d98697781307a1cb537e8e818a775b50432a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Because Werkzeug supports ipv6 natively (and has since ~2010
pallets/werkzeug@13a76262a4), running
Odoo in threaded mode allows binding to an ipv6 address.
However the prefork server is part of Odoo, and only creates
AF_INET (ipv4) sockets. Thus switching from threaded to worker mode
breaks the bind.
Add a family switch on the `http-interface`, so binding to ipv6
addresses also works in ipv6. Gevent already does that switching
internally, so the evented worker works out of the box, it was only
the prefork / workers which did not.
Looking at both the Werkzeug and Gevent implementations:
- https://github.com/pallets/werkzeug/blob/f9906fa6d83dd668f9214acef458419756bbc062/src/werkzeug/serving.py#L607-L614
- https://github.com/gevent/gevent/blob/1e412d35526183b26c1abf2eb658cbef661f5f70/src/gevent/baseserver.py#L415-L433
Both primarily check whether the host contains `:`. Werkzeug also
checks if `socket.AF_INET6` exists, however gevent doesn't bother with
that. Looking at the
source (https://github.com/python/cpython/blob/7d801f245e2021d19daff105ce722f22aa844391/Modules/socketmodule.c#L7419-L7421),
it is indeed possible for `AF_INET6` to be missing, however that
requires specifically compiling Python in an environment which doesn't
support IPv6.
Meanwhile it's also possible to disable ipv6 at runtime, in which case
I'd assume the `socket.AF_INET6` constant is present, and creating the
socket fails, which nobody guards against. Therefore just ignore the
entire thing, it doesn't seem worth the hassle (or the questioning) to
check whether the constant is present, especially since this is only a
concern when the user specifically requires an IPv6 address.
Fixes#35782closesodoo/odoo#114666
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Before this commit, whenever a peer had no selection in the editor, no
selection would appear to the other collaborators. It was therefore
visually impossible to know excaltly to how many people someone is
connected.
Now, we set the default selection to be in the first node of the
document.
Additionnaly, some selection were not displayed because the call to
`getClientRects` did not return any rect. By creating a deep range
through the use of `getDeepestPosition`, we ensure to retrieve the
selection rect.
task-3217719
closesodoo/odoo#114583
X-original-commit: f47b306c5f37a43849975e4b7afb2819c80c809e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Nicolas Bayet <nby@odoo.com>
The comment that describe the
`missingSteps === -1 || !missingSteps.length` condition was wrong.
task-3217719
X-original-commit: 8396878160eceb974c02273f846c180ae4945a7c
Part-of: odoo/odoo#114583
Before this commit, any history step received before the history is
fully synchronised (`historySyncFinished`), would not be processed.
As a fail safe, this commit adds a buffer that will be processed as
soon as the history synchronization is finished
(`historySyncFinished`).
task-3217719
X-original-commit: acb58f921721b162954146f3c5364cb26823265f
Part-of: odoo/odoo#114583
Romeo Fragomeli