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
In the method `isClientFirst`, if
`clientA.startTime === clientB.startTime` is true (which should happen
exceptionally), the code calling `localCompare` would fail as the
method name is `localeCompare`.
task-3217719
X-original-commit: 974e6a5d98b4ab6dc73d63e4acd4c4d3f11a6f0f
Part-of: odoo/odoo#114583
Before this commit, the mutation that add `data-last-history-step` was
added to the history. Without the collaboration, it would not be
problematic but when the collaboration is activated, that step is
broadcasted to the other peers but shouldn't as the mutation is
considered to be technical and should not be included into the
undo/redo mechanism.
task-3217719
X-original-commit: bf45295821495375784f2f817448e2c63f892510
Part-of: odoo/odoo#114583
When contacting the server through the /websocket route, self.env.uid is
never set for the public user as we don't go through the
`_auth_method_public` method.
But through HTTP, it is set which is why guests were not subscribed to
their channels as their self.env.uid corresponded to the public user.
So we use request.session.uid instead, which remains unset for public
users.
closesodoo/odoo#114659
X-original-commit: 7059fdd2c8c36d6741d943ac2b61e971a4d05dcf
Signed-off-by: Denis Vermylen (dve) <dve@odoo.com>
To Reproduce
============
- on settings enable Reception Reports
- for a storable product, create multiple sale orders (something above 10 depending on screen size)
- from purchase app make quotation for same product with quantity that covers these sale orders
- on deliver > allocation, the list is not scrollable
Problem
=======
The `div` containing the data doesn't have a style that makes it scrollable
Solution
========
add `overflow-y: auto;` to `.o_report_reception`
opw-3199037
closesodoo/odoo#114611
X-original-commit: 0c51e9e93fb24ede97411cbcd7bf1e75ded9f7aa
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This commit standardizes both parsers, this commit also leaves all other
(non-dynamic) attributes on the "attrs" object. This means that all
already processed attributes of the nodes are removed from the attrs
object.
Part-of task-id 3179751
closesodoo/odoo#114581
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Consider a form view with a one2many field, which has no form subview.
Also the form view of the comodel (the one2many field's lines) contains
the inverse many2one field of the one2many field. When adding a new
line on some existing record, the form view shows the many2one field as
empty, instead of being the main record.
Explanation: the form view of the line invokes onchange() with the main
record's values (dict) as the value of the many2one field. Inside
onchange(), the field is actually set to a new record corresponding to
the main record. Alas, when that value is sent back to the form, the
new record is serialized as False.
Solution: let onchange() serialize the new record as its origin record
instead.
closesodoo/odoo#114648
X-original-commit: d137ea4915da8d46909fcb082b5a88fd347874a4
Signed-off-by: Raphael Collet <rco@odoo.com>
There is only one module that can be installed, key change was forgotten
during refactoring during initial dev.
closesodoo/odoo#114544
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
The most recent update in l10n_co broke tax repartition: incorrect accounts are assigned to withholding taxes.
This commit fixes the accounts on taxes and adds missing accounts to Colombian CoA.
task-3212928
closesodoo/odoo#114471
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Before this commit, in x2m fields with a parent record dependent context,
the context used to generate default values for a new record by clicking
on "Save & New" could be wrong. It was not based on the edited values of
the parent record.
How to reproduce:
- Go to a form view with a text field (field_a) and an x2m field with the
context { default_field_b: 'field_a' }.
- Edit the 'field_a'
- Click on "Add a line"
A dialog opens with the edited value of 'field_a' as the value for 'field_b'
- Click on "Save & New"
Before this commit:
A dialog opens with the unedited value of 'field_a' as the value
for 'field_b'
After this commit:
A dialog opens with the edited value of 'field_a' as the value
for 'field_b'
closesodoo/odoo#114460
X-original-commit: b22ef9d2cc4119c8cd6e9c72103279e37f043440
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce the issue:
. Change the decimal accuracy of the product price to 0
. Create a storable product and set the Vendor Tax
. Create a purchase order with that item.
. Set the unit price to have 0 decimal places. E.g: 20
. Change the demand quantities to 10
. Confirm the purchase order -> Traceback
Bug:
wrong key word arg used for _float_compare for this PR [1]
Also this PR, remove the rounding on `total_void` in `_compute_all()` to
ensure the price unit have the maximum precision. Usually, the price
unit is rounded following the 'Product Price' accuracy rather than the
currency one.
opw-3136160
[1]:https://github.com/odoo/odoo/pull/105080closesodoo/odoo#114356
X-original-commit: 6906c32626cb222246a895ba2ba5d15b3263935d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit the public user did not have access to tokens or the
possibility of saving payment methods.
When receiving a link to pay the customer (even if not logged in) should
be able to use tokens saved by the parter of the document and also save
new payment methods. This is intuitively correct: as the possesor of the
link, the customer have rights to pay with tokens linked to the partner.
After this commit tokens linked to the partner of the document will be
visible to the public user and also the possibily to save payment
methods.
Task - 2799296
closesodoo/odoo#104472
Related: odoo/enterprise#34792
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
In order to ease the process of setting vats for some users, it was
decided to allow to use a vat number of a single character ('/' for
example) without checking it. This allows to differentiate between
partners for which we did not set VAT yet, and partners exempted from
VAT/without a number.
The VAT check was recently adapted to handle this use case, but the
"same vat" warning was forgotten in the process.
This additional change will disable the "same vat" warning that appears
when two partners share the same VAT number if that vat number is
only a single character, aligning the behavior of the warning to the
changes done in the vat check itself.
closesodoo/odoo#114640
X-original-commit: 4d80d30d0db6993a2fbbab59b935abe07080074b
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Since [1] we removed the isVirtual function from the record, to use the
equivalent isNew, this was made to avoid having two functions with
equivalent behavior. This one was forgotten.
[1] : a73390a42aclosesodoo/odoo#114639
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit when the partner autocomplete field was used
the form title css rules defined in o_field_char were missing.
So now the width: 100% is also applied when the partner autocomplete
is a title and takes the whole available space.
closesodoo/odoo#114610
X-original-commit: b9788544b7101e5a202cf87989bc3f5fc0495249
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
To generate an e-faktur
1. Settings > Users & Companies/Compagnies:
- Create a new company ‘ID Indonesia’:
- Set the state (e.g Yogyakarta (ID))
- Set the country ‘Indonesia’
2. Accounting > Customers > e-Faktur
- Set a range of numbers (which are supposed to be assigned by the
Indonesian government)
3. Accounting > Configuration > Settings
- Fiscal Localization: select the Indonesian package
4. Accounting > Customers > Customers
- Create a new res.partner:
- Set the country ‘Indonesia’
- Check ‘ID PKP’ field
- Fill Tax Address field
- Fill NIK field
- Under ‘Accounting tab’: set both accounting entries (Receivable +
Payable)
- Create a delivery address
5. Accounting > Customers > Invoices
- Create a random invoice with the res.partner set in point 5. as the
Customer
- Confirm the invoice
- Action > Download e-Faktur
Under column ALAMAT LENGKAP the tax Address will be used, but the
delivery address should be used
Follows the official documentation with translation
https://www.pajakku.com/tax-guide/12490/PER_DIRJEN_PJK/PER - 03/PJ/2022
(Article 6, paragraph 6)
Translation:
Paragraph 2 : The identity of the Buyer of Taxable Goods and Services or
the Recipient of Taxable Goods and Services which includes name,
address, NPWP, NIK, and passport number as referred to in Article 5
letter b must be filled in accordance with the actual or actual name,
address, NPWP, NIK, and passport number.
Paragraph 6 : In the event that the delivery of Taxable Goods and/or
Taxable Service is made to the Buyer of Taxable Goods and/or Receiver of
Taxable Service which is the place where the VAT or VAT and STLG payable
is concentrated, but the Taxable Goods and/or Taxable Service is sent or
delivered to the place where the VAT or VAT and STLG payable is
centralized, the following provisions shall apply:
a. the name and NPWP as referred to in paragraph (2) shall be the name
and NPWP of PKP where the VAT or VAT and STLG payable is centralized;
and
b. the address as referred to in paragraph (2) shall be the address of
the place where the VAT or VAT and STLG payable that is centralized
receives the Taxable Goods and/or Services.
opw-2878096
closesodoo/odoo#114087
X-original-commit: 15dc3de31ef07a73078bbe3656f3518a1e9679fd
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
The logic of dirtyTranslatableFields is only needed in one place in
the form view. We will therefore remove this function from the model.
We'll take the opportunity to replace dirtyFields with isFieldDirty
because all uses of dirtyFields want to check with the name of a field
if it is dirty or not.
Part of Task: 3179751
closesodoo/odoo#114560
Related: odoo/enterprise#37866
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
If you specify an empty VAT number in the Contacts app, it will store it
as `False` in the ORM. If a new partner is created through the shop, the
VAT number is set through HTML form submission. It will use `''` for an
empty VAT number. When evaluating the VAT number in Python code, it will
usually be converted to a boolean, so it doesn't matter if it's `False`
or `''`. But in ORM queries those are two different values and code that
checks on `False` to check for the presence of a VAT number can
misinterpret `''` as being one.
This fix replaces `''` values submitted through the address form in the
shop with `False`.
opw-3114246
closesodoo/odoo#114617
X-original-commit: 84106a1d43fa768429f555cd49a72e0fd2adee4b
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Merel Geens <mege@odoo.com>
Before this commit when the user wants to see the burndown chart of a
old large project then the report could take more than 20 sec to be
loaded.
This commit adds 2 indexes one on `mail_tracking_value` table
(`mail.tracking.value` model) and the other one on `mail_message` table
(`mail.message` model) to reduce the load of that report to less than
10 sec.
task-3177072
closesodoo/odoo#114114
X-original-commit: c6b355d471889634ae26a020e14c81e9a315b3de
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
In this commit,
-We Ease the quick creation of tasks by providing shortcuts allowing the user
to set different fields (planned_hours, tags, priority, and assign to users)
without opening the form view.
task-3145203
closesodoo/odoo#112821
Related: odoo/enterprise#37166
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In some cases, wkhtmltopdf might exit with an error (e.g.: a memory
limit). In such cases, we want to show to the user the error returned by
wkhtmltopdf. Previously, this message was only displayed in binary
format (displayed as "Message: b'My error\n'") which is not user-friendly.
We want this message to be decoded so that it is a bare string
(displayed as "Message: My error").
closesodoo/odoo#114609
X-original-commit: 5fc49f8bb24a328e7b735847795bd8e78229cbfb
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
There is a weird deeper low level misbehavior which makes concurent
click to not acts as they should.
Depending on the runbot/tour speed, the misbehavior might kick in and
makes the tour fail.
When you click on multiple options very quick back to back, their click
will be registered and processed one by one, waiting for the previous
one before considering the next one.
You can see that by simply printing a console log in both
`renderListItems` and `_computeWidgetState` method from `s_social_media`
`options.js` file. Then click quickly on the options related to this
snippet like the active toggle and/or remove custom media.
Despite respecting the click order and not overlapping, some click
results (like hidding or removing) will be rollbacked visually and only
the latest click result (starting from the DOM state before the first
click) will be applied.
Long story short: spam click on every toggle option of all the social
media, you will see that all your click will be processed one by one:
- The first media you toggled off will be toggled off
- Then the second media you toggled off will be toggled off but the
first one will be back to toggle on.
It seems to be correctly applying the click result one after the other,
but always starting from the initial DOM state/option widget state
(before the clicks), and not as it should: process the second click
based on the state of things altered by the previous click.
This will need a deeper and longer investigation to fix the root cause.
In the meantime, as this tour is failing multiple times a day, this
commit introduce a workaround to avoid this error in the tour.
task-3212519 (later fix)
runbot-16628
closesodoo/odoo#114600
X-original-commit: e9bd67672ea0517771998ec56f155709cd7c310e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce the bug:
- Add multiple images on a product page
- Go to the shop and edit an image of this product by double clicking
on a small image on the carousel thumbnail
- Save
-> Nothing happens and the image is not updated
The goal of this commit is to ensure that a field of type image is not
`readonly` before adding the `contenteditable` attribute to its image.
task-3122670
closesodoo/odoo#114598
X-original-commit: 36fb7654b785888f100d5163e6cebd788c3c042a
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
An employee with time officer access right would receive the error "You
must be False's manager to approve this leave" even if they were manager
of all the employees.
Now the error message will list all the employee's the user is not
manager of, and it will properly check that the user is manager of all
of them.
task-3220920
closesodoo/odoo#114591
X-original-commit: 76f762008b34ed1322ab318ec3829d038ac8bbe4
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit fixes two bugs with the table of content snippet:
- Before this commit, the scrollspy position for the table of content
navbar was incorrect in fullscreen or edit mode due to the calculation
being based on the presence of the main navbar, which is not present in
those modes.
- Before this commit, when the table of content navbar contained enough
elements to exceed the height of the page, the bottom elements were not
accessible without first scrolling through the entire table of content.
This commit addresses this issue by adding a scrollbar to the navbar,
allowing for easier access to these links.
opw-3115597
closesodoo/odoo#114569
X-original-commit: e5d826e03be1fe8c617ef9a8bb8169ad196657fd
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Those tests check that we do not leak legacy Widget instances.
However, as the form/list/kanban views and fields have been
converted to owl, no Widget instance is created anymore by those
tests.
closesodoo/odoo#114577
Signed-off-by: Georis François (fge) <fge@odoo.com>
The method update_state is called from cron. When the contracts are
updated couple things are checked. There are constraints set that can
throw ValidationError. As a result, none of the contract states are updated.
In this PR we do the following:
In case the ValidationError occurs when we run the cron, we update
contracts that can be updated, and silently pass the invalid contracts.
task - 3069480
bloupbloup
closesodoo/odoo#114566
X-original-commit: bce0d7d0f11d46c671bc2b902d17d80febeefa5f
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, the customize panel backdrop did not fully cover the
customize panel when the vertical scrollbar was scrolled to the bottom.
Steps to reproduce the bug:
- In website edit mode, add a table of content snippet to the page.
- Add a three columns snippet within the table of content.
- Click on an image in the three columns snippet.
- Scroll the customize panel to the bottom and open the filter selector
of the image.
- Bug: the backdrop does not fully cover the customization panel.
task-3090626
closesodoo/odoo#114517
X-original-commit: 672a8cb1632b2e61b87834b47e16e3b2f1c57ad9
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
PURPOSE
Fix and add tests for posting messages in multi company environment as well
as posting on readonly documents when greated by '_mail_post_access'
class parameter.
SPECIFICATIONS
Fix multicompany issues which are generally trying to answer a ping on a record
users cannot reach due to MC ACLs.
Effectively support '_mail_post_access' parameter at chatter level. On readonly
documents it is currently always deactivated while it should respect that
parameter. Some record models allow to post without write access.
Add tests to justify the various access rights avoided using sudo, notably
* check attachments: attachments check is stricter than message check
as it always require at least read and often write access on docuemnt.
This does not work when posting on unreachable documents due to
answering a notification;
* check document access: sudo some document value fetch (like display
name) as access is granted at message creation level and should not
crash due to a missing read access on document;
See sub commits for more details.
Task-3213982 (Mail: fix 'multi-company' post support)
Task-3178885 (Mail: fix 'readonly' post support)
closesodoo/odoo#114511
Forward-port-of: odoo/odoo#114464
Forward-port-of: odoo/odoo#114175
Related: odoo/enterprise#37863
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When being notified on a document they cannot read users should be able to
post, as indicated in message ACLs. However some data preparation prevents
from doing it as ACLs are raised on document level.
In this commit we sudo the call to display_name to populate record_name when
not given. Indeed access is checked at message level so no need to crash in
this specific use case.
Task-3213982 (Mail: fix 'multi-company' post support)
X-original-commit: odoo/odoo@2d73c61136
Part-of: odoo/odoo#114511
When replying on a document they cannot read (notably when being notified)
ACLs raise when trying to check if 'main_attachment_id' is already set before
updating it. This is fixed in this commit. This fixes the recently introduced
'test_post_wo_access' test that does not pass without this fix.
Note that the update of 'main_attachment_id' was already done in sudo. As all
read or update access is now done in sudo, better call the whole method as
sudo in 'message_post' and let '_message_set_main_attachment_id' works on
the given record set environment.
Task-3213982 (Mail: fix 'multi-company' post support)
X-original-commit: odoo/odoo@0375bb227a
Part-of: odoo/odoo#114511
When creating a <mail.message> with attachments a manual check is done on
given attachemnts to ensure user have rights to read them. Indeed otherwise
user could simply give attachments from a protected document when posting
on a document he can read and try to gain information about those.
However sometimes user can post and create messages without having read
access on the document, e.g. when being notified and answering in a multi
company environment.
In this commit we consider that creating a message with attachments linked
to the same document does not require an additional check for attachments.
The check is performed at message level (see its custom 'check_access_rule')
and is considered sufficient. However attachments linked to other documents
using model and res_id are still checked.
This fix helps greening the 'test_post_wo_access' test recently introduced.
Task-3213982 (Mail: fix 'multi-company' post support)
X-original-commit: odoo/odoo@bab0549904
Part-of: odoo/odoo#114511
The attribute _mail_post_access='read' on a model allows user with read only
access on the model to post a message. It was not taken into account on the
client side, making the send message button disabled for user with readonly
access on such model. This commit fixes this issue and now correctly takes
into account that class parameter.
Task-3178885 (Mail: fix 'readonly' post support)
X-original-commit: odoo/odoo@d2b8612cf7
Part-of: odoo/odoo#114511
The attribute _mail_post_access='read' on a model class allows to post on that
model with readonly access. But when providing an attachment such action was
throwing a security error due to the check done on the attachment. Indeed
adding an attachment to a model is modifying that model so the write access
is needed. To solve this problem, we add the attachment in sudo in the
'_message_post_process_attachments' method.
Justification
This is an internal method and we have stated in its documentation that it is
the caller responsibility to check the rights. Actually, the checks are done at
mail.message creation (to which the attachment are linked) by the override
of 'check_access_rule' which calls '_get_mail_message_access' which takes into
account that attribute (_mail_post_access). Moreover sudo is already used
in '_message_post_process_attachments' to link existing attachments. Here we
add a sudo for the new attachments as well.
Note
This fix allows the test 'test_post_with_read_access' to pass (located in
test_mail/tests/test_mail_multi_company.py). But it is currently hard to
reproduce functionally as
- answering an email works as it is executed by the cron;
- replying in discuss trigger a multi company error no matter there is an
attachment or not (so it is another problem);
- sending a message (with readonly access) on a thread from the interface
works without this fix because the attachment are created beforehand and
the part that handle already existing attachment is already in sudo;
Multicompany issues will be solved in the next commits.
Task-3178885 (Mail: fix 'readonly' post support)
X-original-commit: odoo/odoo@f9a6f7f7ce
Part-of: odoo/odoo#114511
qsm-odoo