The text_block snippet has the option to add columns in website but not
in mass_mailing. This is a clear oversight that is hereby addressed.
task-2737896
closesodoo/odoo#83174
X-original-commit: 2738b45deeb6eec7209ece72b9c9dabf8dda0871
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
On opening field html with the inline styles option we were parsing all
the css in the page. This should only be needed when we save. This
commit moves the call to `getCSSRules`back to `commitChanges`.
closesodoo/odoo#83131
X-original-commit: 0d4342317d456ed37f0bf24f00538ef54f847e60
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Both of the native `magic` libraries can trigger an allocation error
if the buffer being sniffed is large. This results in nothing useful
for the user and just triggers and exception when trying to create
large attachments (in the hundreds of MBs).
Fix by implementing the workaround suggested in
ahupp/python-magic#82, under the assumption that it should also work
fine for Debian's python-magic.
The pure-python trivial version of odoo should not have this issue, as
it does not normally copy the source buffer in full, it just seeks and
slices the buffer, and occasionally parses it as a zip (but does not
normally load everything in memory).
Task-2722110
closesodoo/odoo#83190
X-original-commit: 94fc66452f28a8c64b4077d6cc2dd17ea1f00aa6
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
It was not possible to set a different value via the field datas
Add tests
closesodoo/odoo#83175
X-original-commit: b1f047430c97ad4c0da028c1654ce640378e2f51
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The random ids of checklists and stars are preserved in the dom, which
is needed for their readonly check features to work. However, it
complicates testing. This systematically removes these ids in tests.
It also removes the ids when they are not needed anymore (the node is
not a checklist anymore for instance).
closesodoo/odoo#83137
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This reverts bfed1edd26312488dc0f45e8982b51ea4d98db76.
That commit had issues which were hidden by the fact that tests had an
only in them due to a prior mistaken commit. Therefore, it must be
reverted as a proper fix needs to be found.
X-original-commit: 22c2a9dca29adcad84072e3f053ab78b7834f4f3
Part-of: odoo/odoo#83137
The purpose of this task is to use the notification which we currently
have for partner autocomplete and to generalize it to our other IAP
services.
So in this commit, we improve the iap notification for the below views
-> we display a toast in green when the request was successfully completed
(and the user has enough credits).
- when a letter is sent in batch from the list view
- when leads are enriched in batch from the list view
-> we display a toast in orange when the user doesn't have enough
credits with a corresponding 'buy credits' link to the service.
- when a letter is sent in batch from the list view
- when leads are enriched in batch from the list view or when
clicking on 'enrich' from the form view
- when creating a new lead mining request
task-2185306
closesodoo/odoo#66977
Related: odoo/enterprise#16736
Signed-off-by: Arnaud Joset <arj@odoo.com>
Co-authored-by: Nisha Patel <nit@odoo.com>
As there are currently no menu for the implementation
of Sweden localisation Balance sheet and Profit and Loss reports.
Links for those forms are added here.
Are also added a K2 complete COA implementation and
a complete child COA that is BAS compliant.
Tags for more account controls on reports were also added.
closesodoo/odoo#83150
Task: task-2674123
X-original-commit: ebdee5efde067c3bb3abbe0c1c382cca768100a7
Related: odoo/enterprise#23636
Signed-off-by: Julien Alardot (jual) <jual@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
When user tries to print a receipt from a small device, sometimes receipt
is cropped on the right side. This happens because unlike height, receipt
width is not calculated, instead it is equal to the width of the receipt div.
The width of the receipt is equal to the outer width of the receipt instead of div
and the receipts are not cropped anymore.
OPW-2721030
closesodoo/odoo#83142
X-original-commit: c327670e9830506f29c9778bd428ee65964ec622
Signed-off-by: Masereel Pierre <pim@odoo.com>
With this commit, when you perform a search in the command palette,
the part of the commandItem's name that matches the searchValue will
be highlighted.
closesodoo/odoo#82407
Task-id: 2741837
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
There were some discrepencies when adding to/removing from WO Real
Duration:
- When adding time that is brings the total Duration over the expected
duration, the time should be split between the "productive" and
"performance" (i.e. reduced speed) times. This is already happening
when using start/pause buttons, so now it is consistent.
- Use 'id' instead of "Start Date" to determine which time_ids
to reduce/remove since adding a large enough "real duration" value
compared to previous time_id(s) could result in an earlier "Start
Date" for a newer time_id (i.e. results in which one is adjusted/
deleted = confusing). Using "End Date" was considered, but same
non-sequential issue can occur during time split from point above.
- Correctly determine if the "productivity" should be 'productive' or
not (i.e. 'performance') based on total WO duration (not duration
of newly added time_id)
Refinement of Part 4 of Task: 2667151
closesodoo/odoo#80319
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Due to many move values being set only during an onchange, there were
inconsistencies with the values of the products to manufacture and the
MO's components in the following cases:
- when a MO has manually added components/byproducts (i.e. not from a
BoM or a MO with no BoM) = missing values
- a MO is copied = incorrect values copied
- a backorder is made = backorders' moves contained new "-00#" name, but
original "-001" MO did not update all corresponding values to new name
There were also a couple of default values for manually added moves that
were either incorrect or not correctly saving.
Most of these inconsistencies are not visible to the user unless they do
a data export or are playing close attention (e.g. copying an MTO
triggered MO will copy the date_deadline, and this value cannot be
edited by the user.)
Part 6 of Task: 2667151
Part-of: odoo/odoo#80319
Several UX improvements:
1 - Add "Unbuild" filter to MOs (1 or more 'Done' unbuilds) + added
Unbuilds smart button to MO form view
2 - When copying an operation across BoMs, it is annoying that it adds
"Copy" to the end of the name, so we remove that.
3 - Display a warning when using an expired Lot/SN in detailed operations
view (burger window + tab).
4 - Allow adding/removing WO Real Duration + add/remove/edit specific time
time tracking (time_ids) for Done, Unlocked MOs.
5 - Allow search WOs by product to manufacture
7 - Fix validation error message typo
Parts 1-5 and 7 of Task: 2667151
Part-of: odoo/odoo#80319
When trying to identify the user sending an email, do not match anyone
without email.
Sometimes we get an email without a valid From address (spammers or
bugs), the previous code was trying to find users with this email.
In historical databases, we often have many users without an email
address, they should not match the search.
This commit fixes two bugs:
_mail_find_user_for_gateway:
No longer match on the first res.users with no email when identifying
the user using the gateway. This was not problematic (as we have a
fallback on self._uid anyway) but it is more accurate for tracebality
of emails.
_find_members
This method is called from _alias_get_error_message to verify that the
sender is indeed in the group with the followers restriction. On large
mailing list, it is not uncommon to have members with empty emails
(migration, historical reasons,...). Sending an email without any From
was matching on these subscribers without email and the email was
accepted.
These emails are invalid and should not be accepted.
closesodoo/odoo#83122
X-original-commit: 8ec7b92467da2856a496210af1f2232eba6bafb4
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
E documents cannot be selected for invoices and bills which is a problem for companies in Tierra del Fuego, a fiscal exception of Argentina
Steps to reproduce:
1. Install the l10n_ar module
2. Switch to the company '(AR) Responsable Inscripto'
3. Open the Invoicing app and go to Vendors->Bills
4. Create a new Bill and select '(AR) Responsable Inscripto' as vendor
5. The document type '(19) Facturas de exportacion' is not available
Solution:
Add 'E' as journal letter for AFIP responsibility type 'IVA Responsable Inscripto'
OPW-2713805
closesodoo/odoo#83119
X-original-commit: 27edc28a2c19fad80053e668a8c72e7a629e4c1a
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Steps:
- Go into a view and filter on date/datetime
- Select between
- change the input max date manually
- click outside the calendar while remaining in the filter dropdown to "validate" the input
- infinite loop/crash
Same problem/fix as https://github.com/odoo/odoo/pull/78394 in 14.0
opw-2722797
closesodoo/odoo#83107
X-original-commit: 32e2d88ca0a864c91992b2c522ef21dbcb9787a5
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Achraf <abz@odoo.com>
The "Attachments" column was removed in odoo/odoo#76550, but it seems that it
is still needed after all.
closesodoo/odoo#83106
Taskid: 2741777
X-original-commit: 60e4057bc51f9879c756b6efdeb90368ca64b4cd
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Kevin Baptiste <kba@odoo.com>
To reproduce:
1- Configure a 0.05 cash rounding modifying the tax amount
2- Create an invoice using this rounding, for 3€, with a 21% tax (configured with some tags related on tax repartition; a Belgian one for example). => This will create a 0.02 tax rounding move line, for a total tax amount of 0.63 + 0.02 = 0.65
3- Check the tax report => Only 0.63 appears
This is wrong and leads to inconsistencies with the tax closing (which will consider 0.65 because of the tax account used), or the generic tax report (which only considers tax_line_id field, not tag_ids). The tags should be copied from the line we intend to modify the tax amounts of.
OPW 2714411
closesodoo/odoo#83091
X-original-commit: e8e4b0fe3913aadb0c8e1f958b65a24543e6fd9d
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson <oco@odoo.com>
Followup to #82105: turns out we kind-of forgot that records could be
updated with new attachment and the exact same issue could occur.
So with the same reasoning as the previous PR, re-attach attachments
to the current object when updating it.
closesodoo/odoo#83083
X-original-commit: 398070ec1b6ed7d6a8e7c0ab75d45b8a9ad0e0d0
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
In order to provide more transparency, we display any MOs linked to a
SOs via MTO linkage. This includes linkages made via reception report.
Part of Task: 2662730
closesodoo/odoo#79627
Signed-off-by: Arnold Moyaux <arm@odoo.com>
odoo/odoo/pull#79015 fixed some linkages for SO <-> MO, but removed the
linkage for backorders. This made a strange case where a (backorder) MO
could display a SO as being linked to it, but not the other way around.
Discovered during Task: 2662730
Part-of: odoo/odoo#79627
Allow use of reception report for MOs. Same behavior is expected as with
(non-outgoing) pickings. With exception that procurement group linkage
should be included when assigning.
Original Reception Report Task: 2500844
Follow Up Reception Report Task: 2632884
Task: 2662730
Part-of: odoo/odoo#79627
odoo/odoo#35551 removed the section the "byproducts" setting was in, but
the "o_settings_container" div wasn't removed at the same time. This is
mostly not noticeable, but it is annoying when adding new settings after
this setting since the layout will be messed up, so let's delete it now.
odoo/odoo#73939 switched the setting Lock by default => Unlock by
default, but forgot to update the setting title. Let's delete this title
as the setting is now self-explanatory.
Part-of: odoo/odoo#79627
In the next version of Owl, all exported terms are directly available
from the top level `owl` object. This commit aims to adapt existing
imports to this new system. This is done by importing any Owl property
used in files at the top, right after the `import` or `require`
statements.
closesodoo/odoo#82736
Related: odoo/enterprise#23609
Signed-off-by: Géry Debongnie <ged@odoo.com>
Purpose is to have one file per model for: python models, views, data.
Prepares Task-2245823
closesodoo/odoo#83070
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
This commit cleans the UTM module and uses a different file for each model
data and demo in order to clarify organization and ease reading. Each model
owns its own demo and data file. Security file is reorganized per model.
Task-2245823
Part-of: odoo/odoo#83070
Purpose
=======
This commit cleans the UTM module and uses a different file for each model
views in order to clarify organization and ease reading. Each model owns its
own view file.
Task-2245823
Part-of: odoo/odoo#83070
Purpose
=======
This commit cleans the UTM module and uses a different file for each model
in order to clarify organization and ease reading. Each model belongs to
its file.
Task-2245823
Part-of: odoo/odoo#83070
Current Behaviour:
- 'Create' button on hr.attendance.overtime is present but serve no purpose
Behaviour after PR:
- 'Create' button is hidden
'Create' in hr.attendance.overtime is present but has no effect because all the overtime are computed based on attendance.
opw-2730433
closesodoo/odoo#83068
X-original-commit: 7fea5ebcb58c79f93b688ccce90f1f506323414f
Signed-off-by: Kevin Baptiste <kba@odoo.com>
As the FEC can be downloaded by non-french companies, the length of a given vat number might be different than the french's vat.
Currently, if the vat length was lower than 13, it raised an error.
For french companies -> include the SIREN in the name of the FEC file (legal requirement)
For non french companies -> include the complete vat number in the FEC file
closesodoo/odoo#83054
X-original-commit: c3c05bf073a521a662d83c3382e77cb25c59bc3c
Signed-off-by: Laurent Smet <las@odoo.com>
When printing an invoice with tracked products, if there are several
invoices linked to the sale order, the displayed lots may be incorrect
To reproduce the issue:
(Need sale_management)
1. In Settings, enable "Display Lots & Serial Numbers on Invoices"
2. Create two products P01, P02:
- Storable
- Tracked by lot
3. Update their quantity (>1)
4. Create and confirm a SO with 1 x P01 and 1 x P02
5. Deliver the products one by one
6. From the SO, create an invoice INV01
7. On INV01, remove the line associated to P02
8. Post INV01
9. From the SO, create and post the second invoice INV02
10. Print one of the invoices
Error: [1] When printing INV01 (which only contains P01), the lot of P02
is also displayed. [2] When printing INV02 (which only contains P02),
the lot of PO02 is not displayed
When rendering an invoice, `_get_invoiced_lot_values` is called and
provides all data about invoiced lots. However, there are two issues:
- [1] it considers all related SML, even the ones related to a product
not present in the invoice
- [2] when computing the date of the last invoice, it uses the same date
for all products in the invoice although it could be different depending
on the product.
OPW-2637107
closesodoo/odoo#83047
X-original-commit: 9ffd4a9c5755af241a7acc98bc97c790dbb1b84d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Bug
===
Since cd8e0e9f46 the filter "no_share"
has been renamed to "filter_no_share", but the context key
"search_default_no_share" has not been updated in the other views.
closesodoo/odoo#83048
X-original-commit: 131b366e8d841fe7b8d2325941ea8518bcf998a7
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In some cases, the module can patch an event but if it is deleted, some write will fails.
This fix prevent the following traceback:
```py
Traceback (most recent call last):
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1057, in __get__
value = env.cache.get(record, self)
File "/home/odoo/src/odoo/15.0/odoo/api.py", line 889, in get
raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'calendar.event(30350266,).attendee_ids'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/odoo/src/odoo/15.0/odoo/api.py", line 886, in get
return field_cache[record._ids[0]]
KeyError: 30350266
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1057, in __get__
value = env.cache.get(record, self)
File "/home/odoo/src/odoo/15.0/odoo/api.py", line 889, in get
raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'calendar.event(30350266,).show_as'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/odoo/src/odoo/15.0/addons/google_calendar/models/google_sync.py", line 43, in called_after
func(self.with_env(env), *args, **kwargs)
File "/home/odoo/src/odoo/15.0/addons/google_calendar/models/google_sync.py", line 234, in _google_patch
self.need_sync = False
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1217, in __set__
records.write({self.name: write_value})
File "/home/odoo/src/odoo/15.0/addons/google_calendar/models/calendar.py", line 55, in write
res = super(Meeting, self.with_context(dont_notify=notify_context)).write(values)
File "/home/odoo/src/odoo/15.0/addons/calendar/models/calendar_event.py", line 491, in write
previous_attendees = self.attendee_ids
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 3389, in __get__
return super().__get__(records, owner)
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 2603, in __get__
return super().__get__(records, owner)
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1083, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 3276, in _fetch_field
self._read(fnames)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 3346, in _read
self.check_access_rule('read')
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 3553, in check_access_rule
invalid = self - self._filter_access_rules_python(operation)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 3608, in _filter_access_rules_python
return self.sudo().filtered_domain(dom or [])
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 5511, in filtered_domain
data = rec.mapped(key)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 5436, in mapped
recs = recs._fields[name].mapped(recs)
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1176, in mapped
self.__get__(first(remaining), type(remaining))
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1087, in __get__
raise MissingError("\n".join([
odoo.exceptions.MissingError: Record does not exist or has been deleted.
(Record: calendar.event(30350266,), User: XXX)
```
X-original-commit: 2f0c9ca75de616da61e327259d03a8831b8e159b
Part-of: odoo/odoo#83040
Before this commit, the following traceback could be encountered when events were deleted:
```py
Traceback (most recent call last):
File "/home/odoo/src/odoo/15.0/addons/google_calendar/models/google_sync.py", line 43, in called_after
func(self.with_env(env), *args, **kwargs)
File "/home/odoo/src/odoo/15.0/addons/google_calendar/models/google_sync.py", line 233, in _google_patch
self._google_error_handling(e)
File "/home/odoo/src/odoo/15.0/addons/google_calendar/models/google_sync.py", line 177, in _google_error_handling
start = self.start and self.start.strftime('%Y-%m-%d at %H:%M') or _("undefined time")
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1087, in __get__
raise MissingError("\n".join([
odoo.exceptions.MissingError: Record does not exist or has been deleted.
(Record: calendar.event(28241777,), User: XXXX)
```
X-original-commit: e77cbc639032e7f58345942330102b37e7a55971
Part-of: odoo/odoo#83040
When an attendee is deleted in google, we need to sync the odoo attendees and delete the ones that do not exist anymore in google.
Unfortunately, by doing so, we introduced an issue. We filtered attendees that were no longer existing when we looped on the attendee emails.
```py
odoo.exceptions.MissingError: Record does not exist or has been deleted.
(Record: calendar.attendee(YYY,), User: XXX)
```
This commit ensure that we filter only existing attendees.
X-original-commit: 0fb1002c9bb027d1694b834c52e4492a03c8a09d
Part-of: odoo/odoo#83040
In calendar events, the displayed colors are a bit dark and meeting
names in black don't have enough contrast. This commit fixes this
issue and improves general design of the calendar module.
task-2704288
closesodoo/odoo#81184
Signed-off-by: Arnaud Joset <arj@odoo.com>
It helps to debug queries executed in postgresql from Odoo
in order to know where they were called
Enabling the postgresql logs with the following `log_line_prefix`
log_line_prefix='%t [%p]: [%l-1] db=%d,user=%u,client=%h,app=%a '
You will see the following output in the postgresql.log:
... UTC [394452]: [371-1] db=odoo,user=odoo,client=127.0.0.1,app=odoo-740755 LOG: 00000: duration: 0.074 ms statement: SELECT 1
Notice `app=odoo-740755` it is the odoo pid that executed the query
and the postgresql PID `... UTC [394452]:`
Then you will be able to match the odoo.log and postgresql.log using the PIDs
740755 DEBUG odoo odoo.sql_db.connection: ConnectionPool(used=1/count=2/max=64) Create new connection backend PID 394452
740755 INFO odoo odoo.addons: Running SELECT 1
Notice the Odoo PID `740755 INFO` and the postgresql PID `backend pid 394452`
Note: It will require enable the sub-logger
- `--log-handler=odoo.sql_db.connection:DEBUG`
It will helps to debug what process is executing each query in the database
or if a postgressql PID is showing a error log related to connection (not even from a query)
e.g. The livechat stuck and you don't know what happen but you can see the postgresql.log the following message
for the same PostgreSQL backend_pid related to longpolling odoo pid
[394452]: [371-2] db=odoo,user=odoo,client=127.0.0.1,app=odoo-740755 LOG: XX00: Could not receive data from client: Connection time out
closesodoo/odoo#82857
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Antoine Guenet