Client issue: when updating the company of a contact, the Display Name
keeps using the previous company's name, so given Bob in company A, if
Bob is moved to company B the form's title remains "A, Bob" instead of
becoming "B, Bob". More annoying, if Bob is moved back to A the name
becomes "B, Bob".
On res.partner, `display_name` is a stored computed field which
depends on `commercial_company_name` (via `name_get` -> `_get_name` ->
`_get_contact_name`). This is an other stored computed name, which
depends on `commercial_partner_id`, which is yet another stored
computed name, which depends on the `parent_id`.
The dependencies are meh but usually resolve fine, the issue occurs
when a base.automation rule is created with a non-empty
domain (including an empty literal list, which was the case here):
when the first field of the sequence is computed, base.automation's
`_compute_field_value` is called. This calls `_filter_pre`,
which (because `filter_pre_domain` is non-empty) calls `search` on the
model.
This would normally be innocuous as `search` will only flush the
fields used in the search, however for `res.partner` the default
`_order` is... `display_name`. Meaning we flush that computation,
forcing the computation of `commercial_company_name`, but since
`commercial_partner_id` is being computed we reuse its old value (or
something), which is not re-recomputed after the
`commercial_partner_id` computation ends.
So rather than resolve a full search involving an order, filter the
records in-place.
OPW-2427264
closesodoo/odoo#67987
X-original-commit: 221ea6079b2beeb66c4cfa48b237791e1b380c5e
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
To find the main element which scrolls in the page, we rely on its
height being as tall as the body one. The code which checks that was
making a comparison between a rounded value and floating value without
care of the rounding errors that might induce, especially on zoomed
pages.
Fixes https://github.com/odoo/odoo/issues/63306closesodoo/odoo#67986
X-original-commit: 71b6fc7341dfec5e8fc2352c3143b1e324a880f8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Issue
- Install "Sales"
- Switch to "German" language
- Go to Sales -> Products -> Products
- Try to filter on "Public Price" is equal to "2,3"
Not possible to add decimal point at the end (only in middle of number).
Cause
In case the 'decimal point' in DB params is not a dot '.',
the filter input will be considered as 'text' instead of
'number'.
In case of the 'number' type; HTML do already a pre and post
processing, including managing decimal point (who, for example,
is not included in ev.target.value if last char is a '.').
Unfortunalty, the library is not well working with other
language and not supported on every browser, therefore,
must use own logic.
In case of a 'text' type, the value will be send to 'parseFloat'
,then `parseNumber` will replace decimal_point by dot (also one the
issues since needed to display decimal_point according user language),
and `Number` will remove the decimal_point in case of '123,' -> '123',
and therefore we will not be able to write decimals ( apart of adding
the decimal point after writing the whole number...)
Solution
If user input is well parsed, store parsed value in condition.value and
set condition.displayedValue to the input value (an so without updating
input value). Else, replace input value with previous value (who should
be the condition.DisplayedValue).
opw-2463441
closesodoo/odoo#67978
X-original-commit: e795ce5bff14b6b748c1f4a2651946aafdc299f4
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
When adding a variant product, if the option "Variant Grid Entry" is
enabled, it will reset the delivery date of each purchase order line.
To reproduce the error:
(Use demo data)
1. In Settings, enable "Variant Grid Entry"
2. Create an RfQ
3. Add the field "Delivery Date" to purchase order line view
4. Add a basic product (e.g. "[FURN_6666] Acoustic Bloc Screens")
- Keep its delivery date in mind
5. Add a variant product (e.g. "[E-COM12] Conference Chair (CONFIG)")
Error: The delivery date of the first purchase order line has changed
for no reason. Moreover, suppose that in step 4, the user defines a
specific date: the latter will still be changed after the variant
product is added.
When adding a product, the delivery date of the purchase order and its
lines are recomputed. However, an override of `onchange` ensures that
the new delivery date of the lines will be ignored if the `onchange`
concerns the field `order_line`. Here is the problem: when using the
Variant Grid Entry, the `onchange` concerns the field `grid`. As a
result, the new delivery dates are kept. This explains the creation of
`_must_delete_date_planned` in this fix.
However, when returing the result of an `onchange` linked to `grid`, the
result contains the existing lines (on client side) and the new ones
(from the Variant Grid Entry). If the field `date_planned` of the new
lines is deleted, the client will raise an error when it tries to render
these dates (it has no information about their value). Since existing
lines are of the form `(0, <client_id>, <values>)`, this fix only
deletes `date_planned` field for lines with <client_id> defined.
OPW-2454164
closesodoo/odoo#67972
X-original-commit: d2d495bca3e91862470702f1ef07aa27c33d8e2d
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Allow creating a journal entry in the past after having changed the
sequence number reset on newer sequences.
opw-2445559
closesodoo/odoo#67963
X-original-commit: 26a43f23ec2b2490aec0731e25568703729581f0
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, we create a container to add the new options in the
project settings.
This commit removes the container to put these options in the default
container.
task-2387984
closes#66740
Before this commit, if we have for instance 3 tasks called A, B and C
where A depends on B and B depends on A then we have a cyclic dependency.
Another example with the same tasks, we can have a cyclic dependency if
A depends on B, B depends on C and C depends on A.
This commit checks we have no cyclic dependencies when the user adds a
dependency on a task.
task-2387984
closes#66740
Before this commit, we can add the same task as dependency or the tasks
in which the allow_task_dependencies is disabled.
This commit adds a domain to filter the task list when the user wants to
add a task as dependency.
task-2387984
closes#66740
This commit adds two new fields in the project.task model.
The first one called 'allow_task_dependencies' is a related field to the
one project.project model. The other field called 'depend_on_ids' is a
Many2many field will contain the tasks which the current task depend on.
In the form view of project.task model, these fields are added.
task-2387984
closes#66740
This commit brings a new feature for the Project App and project
configuration. This feature is called "Task Dependencies" and it allows
to the user to determine the order in which to perform tasks in a
project.
task-2387984
closes#66740
The landed cost journal (lc_journal_id) is not required by default as a
result it is possible to create a landed cost with no account_journal_id
and thus no company_id this will make the query in
_compute_allowed_picking_ids fail.
Issue caused by: #63742closesodoo/odoo#67675
X-original-commit: 3b9824f57d2bbe30a8a3f63d0decb2101b6b0a90
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
- Settings > Technical > Email > Outgoing Mail Servers;
- Create a new serve with no security;
- Test connection.
Before this commit, a traceback error is raised. This occurs because
SMTPException don't have 'smtp_error'.
Now, the UserError is shown correctly.
opw-2464796
closesodoo/odoo#67712
X-original-commit: f0e478a154b1f15146c7d95e0ffe146bb22b8cae
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Add report name and document prefix on l10n_ar data for
the following documents:
- (60) CUENTAS DE VENTA Y LIQUIDO PRODUCTO A
- (61) CUENTAS DE VENTA Y LIQUIDO PRODUCTO B
closesodoo/odoo#67720
X-original-commit: f61877763c601ee80107d92a414dd9ca13132f0e
Signed-off-by: Josse Colpaert <jco@openerp.com>
We also remove the country_id for the foreign/external_id as otherwise,
it would not be selectable if the country_id of the partner is not Colombia.
closesodoo/odoo#67711
X-original-commit: 46bf5b27aaf374d6fa458170bc936251b8595c24
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Signed-off-by: Josse Colpaert <jco@openerp.com>
odoo/odoo#48362 updated the systems to not show the "Statistics"
section when it's empty, but left an @invisible, leading to not
showing the section at all, ever (which technically does avoid showing
an empty section).
Remove the `invisible` attribute, since the section is now added by
`digest` it should never be hidden. This doesn't fix existing views
tho.
closesodoo/odoo#67964
X-original-commit: 09d8b027e39d1d2eb15abb8d9fe564292fa96d32
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When syncing Odoo with Google Calendar, if one Odoo event has an
attendee with an email address that contains some uppercases, it will
lead to undesirable behavior.
To reproduce the error:
(Need contacts)
1. Create an event
- In attendees, adds a new partner PA
- The email must be valid and the local-part must contain at
least one uppercase (e.g. demoUP@example.com)
2. Sync with Google
3. On Google Calendar, update the event (e.g., add a description)
4. Refresh Odoo Calendar
Error: The event is updated, but the attendee has been removed.
The error comes from both Google and Odoo.
Google Calendar is not case sensitive: if a user creates a meeting on
Google Calendar and adds an email address with uppercases, the latter
will be converted with lowercases. (On step 3, on Google Calendar, we
can notice that PA's email address does not contain any uppercase)
On Odoo side, when syncing the event, the module checks the attendees.
To do so, it uses email addresses from Odoo (with uppercases) and Google
(without uppercases):
https://github.com/odoo/odoo/blob/12cb76bdfe7a5affb7580485473be71cfa37658a/addons/google_calendar/models/calendar.py#L105-L114
`email` comes from Google and `attendees_by_emails` from Odoo.
Therefore, it will consider the email as a new attendee and will run
`find_or_create` to get the associated partner. However, this method
uses the normalized email address to find the partner:
https://github.com/odoo/odoo/blob/12cb76bdfe7a5affb7580485473be71cfa37658a/addons/mail/models/res_partner.py#L50-L63
Thus, `find_or_create` returns PA and adds the latter to the attendees
and partners (even if PA already exists in partners and attendees).
After that, the module checks if some attendees must be removed:
https://github.com/odoo/odoo/blob/12cb76bdfe7a5affb7580485473be71cfa37658a/addons/google_calendar/models/calendar.py#L115-L120
Again, `odoo_attendee` comes from Odoo and `email` comes from Google.
Therefore, it will remove PA from attendees and partners.
This explains why:
- PA has disappeared
- No partner has been created for the email address without uppercase
This fix suggests to normalize the Odoo email addresses each they are
compared with the Google ones.
OPW-2464863
closesodoo/odoo#67950
X-original-commit: 01648d37b9d5ad858d3b60dacfb724a18045f007
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
link tracker tries to get title from HTML, but the url may be not an html page
or too big html to process. It's a waste of bandwidth, but may also lead to a
Server Memory Limit error.
As a solution, make HEAD request and don't proceed to GET request if it's not an
html page or it's too big. Also, limit page downloading to 50KB.
STEPS:
- Have a standard database with link_tracker and mass_mailing.
- Create a new mass mail MM
- Add a link to a large file in MM Mail Body
- Click "SEND"
- Go to Settings / Technical / Automation / Scheduled Actions
- Open the "Process Mass Mailing Queue" or "Email Marketing: Process queue"
- Click "RUN MANUALLY"
---
opw-2457640
closesodoo/odoo#67948
X-original-commit: bdec63cf97e6904604e9f1e0bf3b6f453b6add60
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Enable Notas de Venta Documents, prepare prefix and set type so they can
be used.
Also update csv escape characters for COMPROBANTES COMPRA/CONSIGNACION in
order to proper display the csv en editors and githib.
closesodoo/odoo#67934
X-original-commit: fb62b5e3d99880bce97e1bba0a92dfd5757dab91
Signed-off-by: Josse Colpaert <jco@openerp.com>
If some RR is archived and where the a forecasted demand on the
warehouse location, it Replenishement will crash will due to the
SQL constraint. It happens because the archived RR aren't take in
account in `_get_orderpoint_action` and the method will try to
create a orderpoint with same product + location which
lead to trigger the SQL constraint `product_location_check`.
Also avoid filtered in for loop to improve performance and use the
read_group instead.
task-2439019
closesodoo/odoo#67936
X-original-commit: 6737feef848dc47120cf3d2cca84e033e869c985
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
The`picking_type_id` of the stock.rule wasn't take in account in
the search of BoM because the `_get_matching_bom` with a empty `self`.
fix it by call on the current rule.
X-original-commit: d43e9cb9ad8d1c0c020209de0e8f6ffdcbc960a1
Before this commit, when ribbon was at the right corner of a product
card, this ribbon hid the buttons in list view.
After this commit, in list view, we place the ribbon on the left to
avoid this bug. There was no better solution to fix this in stable.
task-2466120
closesodoo/odoo#67898
X-original-commit: dcddf2125652b03bf4bff385c074fef0b2096f1d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Reduce eye catchiness of warning message when warning the user that
his changes on email and phone will also update customer.
Before, used a ribbon (ribbon_message). It is removed from crm lead model
and also of crm lead form view.
Now, only displays an orange alert sign at the end of the fields when a change
would update the customer profile. Hovering on the alert sign displays
the appropriate message. The warning icon is added on crm lead view for
both lead and opportunity types.
Python compute method of ribbon field is split in two compute methods,
one per boolean field partner_email/phone_update.
Also updates ribbon_message tests accordingly.
TaskId 2456105
COM PR odoo/odoo#66909
UPG PR odoo/upgrade#2258
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit renames the field is_website into is_auto_campaign
for clarity purpose.
The is_website field always meant that the campaigns were created automatically
in some instances. Could be created automatically via a link to the website
or even by simply creating a marketing campaign in marketing_automation.
is_auto_campaign is a better name as it does not wrongly imply that only
the website can generate campaigns automatically, while also pointing
out the automatic generation mechanism.
The utm campaigns behaviour rests unchanged.
LINKS:
TaskID: 2414694
PR: #65824
Enterprise PR: #16238
Related: odoo/upgrade#2146
Related: odoo/enterprise#16238
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The goal of this commit is to add m2m between product and blog posts
to display a list of product promoted by one blog.
And in the future the list of blog that speak about a product on
ecommerce.
task-2267830
Co-authored by jke@openerp.comclosesodoo/odoo#67920
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, clicking on the "add a line" button on a
many2many list field directly opened the dialog without
switching the form into edit mode.
This is incorrect, the form needs to switch into edit mode otherwise
the selected records are saved and cannot be discarded.
closesodoo/odoo#67919
X-original-commit: 3608e724c6099f0eff5f14cbd844e0d7507d0d1d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since the quick edit behaviour has added, embedded lists
can be edited and display the "add a line" buttons in a
readonly form but not display the remove buttons
This commit fixes that inconsistency.
X-original-commit: 7cc17a345bc9cbe165d061300d91d1ac0e583fc1
In calendar module there is one typo in action_mass_mailing
button's string.
So replace the 'EMAIl' to 'EMAIL'.
closesodoo/odoo#67535
Taskid: 2478549
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit:
- Edit mode, open image dialog
- Upload an image to the media dialog
- Reclick on Upload but don't select an image, close the browser image
selector
- This will trigger the input change event, as the input was emptied
This is needed since in later commit, `_addData()` will do some code outside
of the `files` loop, which is useless if there is no files selected.
In thise case, the issue would be that it would open an empty toastr.
task-2345082
Coming from #65828Closes#68326closesodoo/odoo#68340
X-original-commit: 94c45412714c1263788b2567ce3c9581453b2cd4
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since the image util method `image_base64()` is converting BMP images to PNG
automatically[1], there would be a mismatch between the attachment content type
and the attachment mimetype.
- Content type: retrieve with `base64_to_image(data).format` -> return PNG as
the image data was converted from BMP to PNG
- Mimetype: set on `write()` and `create()` with `_check_contents()` which
call `mimetypes.guess_type(file_name)`.
BMP image `my_file_image.bmp` would have a mimetype set to BMP
The computed field `image_src` would return `False` since the image.mimetype
would be BMP, making the dialog picker not showing the image but loading
`http://localhost:8069/false` instead.
[1] https://github.com/odoo/odoo/blame/097f29d0f6a5b295c81fd074665dbd261eaf12fb/odoo/tools/image.py#L124
task-2345082
Coming from #65828Closes#68326
X-original-commit: ef5b108b781df73342bb99342a1116fad86d3b58
Previously, when selecting certain options, especially ones which had
slow updateUI methods, the selected value was sometimes reset to its
previous value. This was caused by a race condition in which, when a
snippet option updated its value, it would wait for options on the
parent snippet editors to update all of their options' UI, but it
incorrectly only waited for *one* of the snippet editors to finish
instead of waiting for all of them.
This commit fixes that by stopping the event propagation and triggering
a new event that will let the direct parent know when all parent editors
are done updating their options' UI before signalling that the UI update
is done.
task-2487578
closesodoo/odoo#68341
X-original-commit: 7623a0c771495cd41bf40af37c0d2b6e4beb7cdc
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Arthur Detroux <ard@odoo.com>
Let's assume an x2many list with an onchange. When a sub-record is
modified, an onchange is performed, and it may update other records
in the relation (e.g. the debit/credit case in accounting). This
commit ensures that modifiers are correctly re-evaluated in that
situation, so that they are up-to-date with the new x2many values.
task-2373929
closesodoo/odoo#61911
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit introduces a many2many as a standalone, reusable
UserValueWidget. This widget is built on top of the ListUserValueWidget
which was until now only used in website form that had to be updated to
allow more generic use of the widget.
Part of https://github.com/odoo/odoo/pull/67832
task-2274732
Issue
-----
- Currently the cron can take too much time and timeout.
In case of timeout process data are rollback.
The sync per user also crash and stop the process for all user and make
the transaction rollback
In both case we cannot ensure that all user will end up synchronized
- The real time sync can end up in deadlock:
If you create a holiday, it trigger a write on the user and the
creation of an event that will be synchronize with google
The synchronization may ask for a new token if this request fail
a new cursor is create to empty on the user the refresh token.
2 cursor that are trying to write on the same record => Deadlock
- Bad refresh token management
When the refresh token is not anymore valid it's erased but
the calendar_token and validity are kept. Is odoo consider
the token valid it will try to sync an event with google|microsoft
despite the refresh token is not valid anymore. Of course this lead to
an error and the impossibility to create an event anymore without
manually wiping the calendar_token and calendar_token_validity
- Error 401 are handled in context manager
(google|microsoft)_calendar_token, but get_*_calendar_token never raise
http error only user error.
Solution
---------
- Improve cron resilience
- Commit between each user and rollback in case of issue for a user
- Solve the issue when stop < start
- Solve issue with rrule not being the first element in the list
of recurrence
- Improve perf when searching for organizer
- In order to limit the volume during the first synchronization, we only
synchronized event from x days in the past to x days in the future with
x = 365 by default
- Limit the number of event to synchronize to google each time to 200,
since this operation is time consuming (1 request is sent per event)
- Avoid deadlock
A new cursor is not needed, we only need to ensure that write on the
user is done with a clean cursor and will be commited despite the error
raise. So rollabck before the write and commit explicitly afterwards
- Erase properly all the token and the token validity if the refresh token is not valid anymore
- For google calendar, erase also the token in case of 401
error: Wrong client id, this mean the database parameter have been
change and all the user should reconfigure the synchronization
- Directly handle error 401 with error 400 in refresh_token method
closesodoo/odoo#66250
X-original-commit: 486f69abad6226e5ce016ad89a0eeb103d709a3f
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
*: web_editor
The purpose of this commit is to control the hue and the saturation of
the gray palette.
task-2362091
closesodoo/odoo#66428
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Adds a new UoM category (surface) and two UoM: m² and ft²
Could be useful for some kind of products like paper or fabric.
task-2443585
closesodoo/odoo#66174
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Purpose of this merge is to make templates easier to preview and edit as
weel as to improve their content.
This is achieved notably by lessening use of custom rendering context and
trying to fix as much error-prone jinja statements.
In this commit we also make ``calendar_template_meeting_reminder`` template
looking more like other templates. There were some rendering differences that
do not seem really wanted.
``calendar_template_meeting_reminder`` was also using an old ``force_event_id``
key not replaced by recurrent_id field on attendee.
This merge improves few strings of the invitation mail being sent while
booking an online appointment. Online appointment is computed based on
``appointment_type_id`` field being defined. Some tweaks in wording made it
necessary to know if recipient is the responsible, customer or an added
attendee on the event, leading to some tooling code added on event model.
The main changes includes
* for customer, remove the CTAs to accept / decline event as attendee are
automatically set as accepted;
* depending on recipient, improve wording of the mail accordingly and mention
appointment type in the mail;
Some code reodering and cleaning is also performed in this merge to ease
reading and understanding of calendar event and attendee models.
LINKS
Task ID-2199620
COM PR #64925
ENT PR odoo/enterprise#15914
UPG PR odoo/upgrade#
Related: odoo/upgrade#2282
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to make templates easier to preview and edit as
weel as to improve their content.
This is achieved notably by lessening use of custom rendering context and
trying to fix as much error-prone jinja statements.
In this commit we also make ``calendar_template_meeting_reminder`` template
looking more like other templates. There were some rendering differences that
do not seem really wanted.
``calendar_template_meeting_reminder`` was also using an old ``force_event_id``
key not replaced by recurrent_id field on attendee.
This commit improves few strings of the invitation mail being sent while
booking an online appointment. Online appointment is computed based on
``appointment_type_id`` field being defined. Some tweaks in wording made it
necessary to know if recipient is the responsible, customer or an added
attendee on the event, leading to some tooling code added on event model.
The main changes includes
* for customer, remove the CTAs to accept / decline event as attendee are
automatically set as accepted;
* depending on recipient, improve wording of the mail accordingly and mention
appointment type in the mail;
Task ID-2199620
COM PR odoo/odoo#64925
ENT PR odoo/enterprise#15914
UPG PR odoo/upgrade#2282
Co-Authored-By: Krupal Oza <koz@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
Victor Feyens