The res.users class contains special fields that bypass access rights.
These are designed to allow a user that does not have the possibility to write
on res.users to modify their own fields, such as the mail signature.
Create and write are overriden to make it so, however the check_access_rights
isn't.
Since this method does not work at field level but at model level, there is no
easy way to resolve the incoherence.
Uploadding an image to a signature would add an attachment to the signature;
before being created, an attachment checks if the user has the rights to write
on the target model. The incoherence thus make it fail.
We add a special case when creating an attachment so that a user can write on
itself.
opw 1871243
- Activate lots and SN
- Go to Inventory > Inventory Adjustments
- Export a record
- Select the field 'Inventories > Lot/Serial Number'
The `name_get` of the field is exported, not its XMLID.
This is because the parsing made in order to limit the depth of export
is made on the label, not on the field name.
Actually, it is not clear WHY this limitation exists, but we keep it for
compatibility purpose.
opw-1877092
When a column is created in the kanban view, the context of the window
action is fully given but it may contain default_{field_name} context
keys that are intended for the action model.
eg. on a product.product view we could have {default_type:'product'} in
the context, if we grouped by company_id and created a new company, we
would the context is propagated and we would try to set type='product'
on the company (which causes an error).
Without the change, the added test fails with:
default_* should be removed from context, actual: "true", expected: "false"
opw-1879064
closes#26676
Steps to reproduce the bug:
- Let's consider the today date = D
- Set on your preference a timezone which has another today date = D+1
- Go to CRM > Configuration > Activiy types > Call
- Set 0 as # Days
- Go to CRM > Pipeline > Click on a lead
- Schedule an activity of type = Call
Bug:
The Due Date = D instead of D+1
opw:1877217
When an inline editor is eg. in a form view, the focus is always stolen
by it.
This is because we trigger a mouseup on the editor to update its
toolbars values and informations.
In 10.0 this was not necessary since the default values were sanely set
when the editor was inside the DOM. In 11.0 the editor is not in the DOM
when this is being done and the info was wrong (eg. NaN for text size).
With this commit, we don't steal the focus and get the default like it
was done in 10.0 instead.
fixes#26366
opw-1874880
closes#26582
Steps to reproduce the bug:
- Create a user U with manager inventory access rights and no right in sales
- Create a SO and validate it, it will create a picking P
- Lock the SO
- Log with U and try to print the delivery slip of P
Bug:
A access right error was raised.
opw:1878504
If we do:
- one change that will be saved in history
- go back to the document before any change
- do other change
we can easily get in a state were the history is no longer recorded.
The history is kept like this:
- pos: our position in the history
- aUndo: the snapshots of history
- toSnap: the last history snapshop that is to be saved
so for example if we start without change (at originalState):
{pos: 0, aUndo=[], toSnap=null}
Then we do two changes (change1, change2):
{pos: 2, aUndo=[originalState, change1], toSnap=change2}
If we make an undo, we will get to:
{pos: 1, aUndo=[originalState,change1,change2], toSnap=null)
If we make another change (change3):
{pos: 2, aUndo=[originalState, change1], toSnap=change3}
So the history after the position is removed.
But when we get back to the original, the state would forever be:
{pos: 0, aUndo=[originalState], toSnap=change85}
because when doing a change, the code only removed history from the
max(pos, 1) index.
opw-1870119
closes#26701
In the editor in a table cell, when we press UP/DOWN keys:
- we have default editor/browser behavior if there is content before
(UP) or after (DOWN) the element we are currently on
- else we go to the previous (UP) or next (DOWN) row if available
- else we go to the next content if available
- else we have the default editor/browser behavior
But when checking if there is an element before/after the content, we
did not take into account if there was an ancestor node inside the cell
that had content after, so for example with this structure:
```
<table>
<tr><td>
<p>hello <b>world</b></p>
<p>cruel</p>
</td></tr>
<tr><td>
<p>bingo</p>
</td></tr>
</table>
```
if the current range was on 'world' text node, we would just check if
there is content after this text node, not if there is content after its
`<p/>` ancestor.
Before the fix we would get on the next row, after we would have default
editor/browser behavior: ie. if cruel is on another line, going to this
line.
opw-1870119
closes#26701
Be in a grouped kanban view with progressbar with limit 10:
- records 1 to 10 are loaded on a column
- do "Load more..." on a column => records 11 up to 20 are loaded
- do "Load more..." 2nd time => records 11 up to 20 are loaded
- do "Load more..." 3rd time => records 11 up to 20 are loaded
- ...
While in reality it should be:
- do "Load more..." 2nd time => records 21 up to 30 are loaded
- do "Load more..." 3rd time => records 31 up to 40 are loaded
- ...
This was caused by the progressbar reloading the column's group. This
set the loadMoreOffset to 0 thus forgetting the current state.
Without the change, added tests failed with:
records of column are loaded => actual: "1,2,2", expected: "1,2,3"
opw-1878359
closes#26628
Suppose you select a customer for a sale order.
You type the beginning of his name "think", and a name_search is triggered
which finds matching results, with first result "Think Big Systems".
There are three ways to select it: click, enter or tab.
Now there can be a warning set on this customer
("Bad client, only accept cash", or "good client, offer discount").
In that case, clicking on tab would trigger the onchange displaying the warning,
but it would also set floating to true, which means a dialog to create client
"think" would appear.
This happens if the onchange is delayed, and thus the call to reset the floating
state is triggered only after the focusout completed, instead of before.
Coauthored with @aab-odoo
opw 1866619
opw 1874475
With a fixed price delivery method, the error message was not displayed when
the address doesn't match.
Inspired from function base_on_rule_rate_shipment
The error message was not clear enough.
opw:1879204
This commit fixes two bugs:
- a8469c45 was fixing the case where the first line was not 'code' but broke
the usecase where a po started with code line
- Correct the usecase where a pot and po file do not have the same line of code
by matching on res_id=0
This avoids to have a pot expecting a code message at line 42 and a translation
at line 43
Closes#26722
Overwrite vendor reference only if there is a PO linked to the bill.
Otherwise, any addition of product will erase what the user just typed.
Closes#26734
The pivot view didn't take into account the widget set on the fields.
In particular this was a problem for float fields that store time values.
They are now displayed with float_time if declared as such in the view.
opw 1876445
`firstName` and `lastName` should be filled in for Australia, but the
implementation is not correct since:
- it assumes that the name is first name + last name, which is not the
case in all countries (e.g. France)
- it doesn't take into account that the name could be a company name
This reverts commit 26974d4e5f.
- Create an event, add an attendee
- Click on the stat button 'Mail Attendees'
The domain is shown as 'Event', '?', [id].
This is because the domain selector widget doesn't support the `in`
operator. Supporting it is not trivial, since ultimately `field_utils`
cannot parse a list of ids for a Many2one. It's less intrusive to change
the domain, since a standard use of the method will simply contain a
single id.
opw-1878322
The override of fields_get adds "virtual" fields corresponding to
groups.
If for example we make "res.users" have inherit "mail.thread", we get
these "virtual" field as if they had "track_visibility", since we do a
"fields_get" with fields having track_visibility expecting to only get
back "track_visibility" ones.
So the system would then fail trying to track visibility on fields like
"in_group_5" and for example a res.users could not be created anymore.
With this fix, we fix the fields_get so it respect the fields we ask of
it.
fixes#22332
opw-1878654
closes#22338closes#26705
Co-authored-by: Wolfgang Pichler <wpichler@callino.at>
for the payment processor wespac there are required fields we do not send.
required:
•Card Number
•Expiration Date
•Amount
•First Name
•Last Name
•Address
•City
•State/Province**
•Zip Code (Postal Code/Postcode)**
•Country
•Email
** These fields are optional if the billing address is not in the U.S. or Canada. If the address is in the U.S. or Canada, the two-digit State/Province code must be provided, along with the Zip/Postal Code.
Some users are confused by the generic error message asking to confirm a sale
order that is in locked or cancelled state.
We add specific error messages in these two cases.
opw 1871019
4e5119c6e5 didn't account for
`tools.config['workers']` being `None` on windows, resulting in the
entire thing crashing when trying to execute `None > 1` in Python 3.
Fixes#26447
- Product tracked by lot:
3 units of lot A
2 units of lot B
- On the operation type 'PoS Order', only tick 'create new SN/LN'
- Make 2 PoS orders for 2 units.
- Close the PoS session.
The first picking (2 units of lot A) is done, but the second picking is
ready but not done.
The issue comes from the world famous error:
'Cannot set the done quantity from this stock move, work directly with
the move lines.'
We apply the same logic than in commit f0028bc837
opw-1878256
The domain was instantiated without being given any evaluation context.
As a result, the uid variable was not defined,
crashing the js if present in a user-defined filter.
opw 1866852
Create a PO and assign any string to the Vendor Reference field. Confirm
and create an invoice.
The Vendor Reference field on the invoice is empty, while it is expected
to be filled in.
opw-1879379
Christophe Simonis