Add new activity type 'Email with Template' for demo purpose and add a mail
template for it.
task-1887986
closesodoo/odoo#38944
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
- Create a customer invoice.
- Validate it.
- A payment reference (`invoice_payment_ref`) is given.
- Refund with option 'Full refund and new draft invoice'
The `invoice_payment_ref` field is kept on the draft invoice, while we
want a new reference since it is a new invoice.
opw-2159166
closesodoo/odoo#42832
X-original-commit: 77c28421e6c7711e3d3c39dbece4e2bfa0b26b5c
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, pointer events were prevented on all checkboxes in readonly
list views. That meant that the boolean_toggle widget for instance could not be
properly toggled in a non-editable list (which was the purpose of such a widget).
Now, pointer events are enabled only if the checkbox :
- is in a selected row AND does not have a readonly modifier
OR
- has a widget applied on the field.
Also ensured that the field widgets in the list view multi edition confirmation
modal are not interactive.
We cannot test the `pointer-events` property interactions as it does not affect
manual event triggering used in tests.
Task 2154055
closesodoo/odoo#42848
X-original-commit: c7ee164d572e01fcb565001fd5e62fe1278b5cd8
Signed-off-by: Julien Mougenot (JUM) <Arcasias@users.noreply.github.com>
In developer mode: the fields campaign/medium/source appear twice
in the "Other Info" Tab of the sales orders.
Task ID - 2167971
closesodoo/odoo#42842
X-original-commit: 916d3adb1146963a2fe62c262260bfc757fcd5ea
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Consider an x2many field with `context={'active_test': False}`. The
value of that field should always contain inactive records, as the
field's own context overrides the context of the current record.
closesodoo/odoo#42824
X-original-commit: a2fc37adc179fb8bfc11251137334f0a43c58135
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
PURPOSE
=======
It is odd that the 'configuration' menu item on the 'Members' app
does not unfold on configuration items like in all other apps.
Even though there are only membership products to configure, the
action should still have its dedicated menu item for consistency
across modules.
SPECIFICATION
=============
'Move' action membership.action_membership_products to a new
'Membership Products' menu item under 'Members/Configuration'
closesodoo/odoo#42744
Taskid: 2167683
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In v12, it was possible to add an internal note on a journal entry.
In order to retrieve this feature, we add the field in the 'Other Info'
tab. Note that this tab is only displayed for journal entries, not
invoices. Therefore, the same field is not displayed twice.
opw-2167108
closesodoo/odoo#42825
X-original-commit: 764536c0620c9d80d1e9c59a8c8186c9e33861eb
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Since revision cb618e9a99, `previous_product_uom_qty` is not
set in the context anymore but passed as parameter.
opw-2146706
closesodoo/odoo#42820
X-original-commit: 33741910e32680e644e2509d108b0cd4a4138013
Related: odoo/enterprise#7565
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- The module `website` instanciate the environment bound to
request before `_dispatch` is called.
This causes issues with with routes that create their own
psycopg2 cursor.
To be more precise, the issue that allowed us to discover this
instanciation is linked to the module `auth_oauth`.
The route `/auth_oauth/signin` is a `none` route that receives
a database name. It uses the db name to create a cursor and
an environment manually to process the OAuth signin, log-in the user
then assume it is safe to now use `request.env` to process the rest
of the code.
But here, since a cursor has already been created in `request` before the
route had the chance to commit its changes to `res.users`, the
changes made in the route `/auth_oauth/signin` are not available.
And this causes issues with the computation of the session token
done in the method `_compute_session_token` in the model `res.users`.
It uses the field `oauth_access_token` to compute the session token.
But since, the cursor in `request` is in a transaction that is not
yet aware of the changes made on this field, it will compute a
session token using the old `oauth_access_token` and store this
outdated token in the client's session.
Then here depending if you are using a multi-worker or a multi-thread
Odoo, you either are never signed in or your session is expired
after a cache cleaning (the method `_compute_session_token` is cached).
closesodoo/odoo#42808
X-original-commit: ceec103826ae2a18c63b48c17850d035e352fa3b
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
When an account of type receivable or payable is used as default debit
account or default credit account of a journal of type sale or
purchases, an error is raised.
Now, constraints are added to avoid this.
opw-2151924
closesodoo/odoo#42817
X-original-commit: 0c90eb50b352ee003d52ef927260d1b9310ec69f
Related: odoo/enterprise#7562
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Create multiple tax and assign them to the same tax group. Now create an
invoice, in the line add all the taxes in the group. Save and click on
"Preview". In the tax recap the tax group will be reported applied on a
total equal to the number of used taxes multiplied by the total of the
product. This append because in the calculation the tax are included
multiple times and not just once per group.
opw-2158989
closesodoo/odoo#42814
X-original-commit: 261c528b87bd8e5b5e4cd0dbaf01c49197bf192c
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This is a followup to the fix made in
99615ff6cc.
When calling JSON.stringify to undefined, it results to undefined, thus,
it is necessary to check if the value is undefined before JSON.parse'ing
it.
closesodoo/odoo#42812
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Issue from rim:
In runbot 12.3
- Go to Purchase
- Create a PO with one product line: qty 1 / unit price 1000
- Validate the PO and create the Invoice
=> DON'T VALIDATE THE INVOICE YET
- Go back to the PO, change the unit price to 2000
- Go back to the invoice, validate it
==> the PO is marked as "fully invoiced" because the qty "1 unit"
is counted as "invoiced"
=> we should not be able to change the price of a line that has
already been invoiced, even in draft
Cause
It seems that in all the PO's invoices state, we can edit a PO line.
No restriction?
Solution
Set the line price column to read only when they have a linked
invoice.
OPW-2161477
closesodoo/odoo#42797
X-original-commit: b31c04040a2d7fe83741dec2d3a622487b7e46c3
Signed-off-by: Jason Van Malder <jvm-odoo@users.noreply.github.com>
Before this commit, negative numbers are never rendered as human readable (e.g. 34000 -> 34k).
closesodoo/odoo#42789
Taskid: 2160790
X-original-commit: b51877c4c4c9d8cd873dd0205954fd807d62ee01
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce the bug:
- Create a journal entry JE
- Add a partner P and an account A
- Click on 'Add a line'
Bug:
A line with P and A was suggested instead of only P as smart suggestion
opw:2152827
closesodoo/odoo#42699
X-original-commit: b71143bb3d68ed5ecab97e45699f001914bbc00f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
`run_action_` hooks don't always return a value, in which case
invoking run() over RPC will raise a TypeError (though the call itself
should still succeed).
Somewhat oddly, "standard" hooks (e.g. in mail) generally do
things safely and return a `False`, but the "builtin" hooks (code,
object create and object write) tend to return nothing, and thus break
when invoked over RPC.
Fixes#42268Closes#42272closesodoo/odoo#42804
X-original-commit: 9ad01ef242afc9602d4a1470cb321374129f29b9
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit, the default `expiration_date` wasn't set when the
move line was created with the help of multiple assign serial numbers
button or when user wrote/copy-pasted a list of SN/LN.
task-2166230
closesodoo/odoo#42809
X-original-commit: ff6126e8077031fb20eada5f3f9d8fd8a4a4c56a
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this commit, in the move line view, the field `expiration_date`
was readonly even when it must be editable. It was because the condition
who defines if the field is readonly or not was wrong.
Also, removed the field `expiration_date_readonly` as it mainly referred
to `picking_type_use_existing_lots`, and use this latter instead.
task-2166230
X-original-commit: f1b8426919dc049df447d50ed3ac365eec2897c3
Before this commit, a promotion program such as 'Buy 10, get 2 fore free'
would have only added a single product in the reward. This commit fixes
this problem by ensuring that the quantity for the reward product is computed
as the number of times the program is applicable multiplied by the configured
reward quantity, instead of just counting the number of times the program is
applicable.
closesodoo/odoo#42768
X-original-commit: 4251d44c2e635e0a78d2320cf020777ad5c55722
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Key input is handled in an evdev event loop. Before this commit the
state of modifier keys like shift, caps lock, ... were read when the
event was being processed. This doesn't always work because the evdev
events are processed asynchronously, i.e. when key A is being processed
in Python key B may have already been pressed.
Some devices that type fast, notably the Magtek card reader, this leads
to modifiers being applied to the wrong characters. Here's an example
before the patch:
5895000020000006^TEST/VAnTIV^251200000000000000?;4895000020000006=251200
000000000/\0600\0dD15ac71B75BA468E51F4e657529ADF6E3BDAC0A86A59B7adA12029
22F64BB55E74880A1908AD08AFC9372ADe21FD1E74D409C912C1A5|5C3D07B727DE46DaF
B6D8ED2007DB219F49FAC1311F0fa01474FC5BC621F33F915BE77D8DAF5E69A||6140300
0|076C0B3B0704CD78D7CF7Dc5B2ED3F0Ca3ad2e6c88d1F2310B7DB96973b4D556c2f9e4
016C60a7DB581990567FE5656E02C27276FA43BFE|B2ECCDE070215AA|336a4f78bb3c4C
\901209b2eCde000f3\4fC\100
This is what it looks like after the patch:
%B4895000020000006^TEST/VANTIV^251200000000000000?;4895000020000006=2512
00000000000?|0600|FE511F7BA7C38A4FA85D0135E58DDC798E557819356DADA132ECBE
D95184CCC77D7E2B1AE7E8AB076488B9757CA2A046C70590D01FA86217|5DAFE6EC44372
A3EF0358D42D08D9246DD8D2837150954B758199207697EFEB08A71B38B2E1690CE||614
03000|584CB8EBE3B17D2828C3B010DFB4E63E9F5036705CF7E547707DC75A9408E958DC
A3052B03031EA0F3B1F1163E40EF3F542B70F9FFD7912D|B2ECCDE070215AA|21352532D
D6E7334|90CDE0001FA|06A6||1000
These are some of the issues visible in the above example:
- there's a 5 instead of a % (on QWERTY SHIFT-5 is %)
- the n in VAnTIV is lowercase
- there's many /'s which should be ? (on QWERTY SHIFT-/ is ?)
- there's many \'s which should be | (once again on QWERTY SHIFT-\ is |)
To solve the issue, we read the state of the modifiers in the same event
loop.
opw-2122553
closesodoo/odoo#42767
X-original-commit: caa4c7ef6d23f695827b58e60a013a9438eb67cf
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
It behaves exactly the same as a barcode reader, and pos_mercury uses
the barcode nomenclature to make it work. For reference, the full name
is:
Mag-Tek - USB Swipe Reader
opw-2122553
X-original-commit: 635f1ea8527f4489b8c56b5d18856c7d2c60737e
Issue
- Have firefox
- Go to any chatter
- Open full editor
- Write some "test" words with line breaks
- Select one of your "test" words
- Drag & drop it somewhere else in the editor
Welcome on test.com! (redirected)
Cause
Summernote doesn't preventDefault on drop event, so firefox
think we want to go to another URL.
Solution
Add the preventDefault manually.
This reveals another issue which is solved by importing
this PR's code https://github.com/summernote/summernote/pull/3327
(with adaptation for our dinosaurus version)
OPW-2158112
closesodoo/odoo#42759
X-original-commit: 197145ac19fd65dcfbcbae81c8b5dd54025185a4
Signed-off-by: Jason Van Malder <jvm-odoo@users.noreply.github.com>
Currently the 2 CRM calendars (Pipeline and Leads) only display leads
when they have a linked activity. Therefore creating new leads within a
calendar view was confusing since users could not see the new leads
without switching to another view (note that new leads could not have
activities linked to them under current design and expecting users to
know to add an activity to a new lead to immediately view it in the
calendar view is unreasonable.)
This commit makes it so users can no longer add new leads to calendar
views in crm module. Current behavior of being able to edit leads
already in calendar is untouched.
Part of
Task: 2126530
Previously it was always possible to create within the calendar view.
For some modules this did not make sense and lead to confusing behavior,
for example: a new model instance created in the calendar view that was
not viewable in the calendar view, but was viewable in other views. By
adding a 'create' attribute (to be used in view xml), we allow users to
choose whether or not they want a calendar view to be able to create.
Note that this change does not affect the edit ability of calendar views
for existing instances.
Part of
Task: 2126530
Before this change, fields.Reference displayed into the popover of
a calendar view was always empty. This was because the popover view
generated from a double click on an element in the calendar view
creates its own recordModel in JS and the function to create this
record did not handle the reference field case.
This commit detects if a reference field is defined into the record
and adds the necessary processing to process its value and creates
the corresponding dataPoint.
opw 2151635
Closes#41262closesodoo/odoo#42707
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
* add a runtime warning when an onchange method contains the string
'domain'
* add a lint test to forbid the string 'domain' in onchange methods,
this is easy to defeat (e.g. `dict(domain=...)`) and can have false
positives (literal `'domain'` strings for reasons other than an
onchange result) but overall it seems to work nicely
* implemented as a non-pylint test as pylint takes ages to run. While
at it, remove the long-disabled and long-useless
PEP3110TokenChecker (checks for `except Exception, a` which is a
syntax error in P3)
Task 2115472
closesodoo/odoo#41918
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This reverts commit d39a51259e93b84184379a1fc9b824dad94e5ea5.
This view was technically clean and useful to detect configuration
issues (wrong view_location_id for example) but was not liked by our big
boss because "a group by parent_id does the same thing".
task-2166904
closesodoo/odoo#42734
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Remove color and capacity fields of mpr.workorder unused
and coming from commit : 2ddc35a530 .
closesodoo/odoo#42498
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The credit notes must be included in GSTR-1 report.
opw-2161465
closesodoo/odoo#42733
X-original-commit: 8b956b60e55ef24c552925cae0f0ae8fadd07c5d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Without this flush, partner computed fields are not computed when creating
the company, leading to a cache miss. It is due to the quite complex model
introduced in base_address_extended with multiple related / computed / inverse
fields.
How to reproduce
* have base_address_extended installed;
* create a company with address bits (street_name, street_number,
street_number2);
* encounter a nice cache miss bug (partner<ID>.street_number):
Original task ID 2068145
PR odoo/odoo#42701closesodoo/odoo#42722
X-original-commit: 69ea928828fca06c9b0f589e23ca3c0d4c387ab0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
This commit reverts commit 44221cffac called "[FIX] base_address_extended:
Fix cache miss bug" .
Indeed it fixes the cache miss bug but introduces another one which completely
breaks address encoding.
How to reproduce
* create a company with address bits (street_name, street_number,
street_number2);
* update one of those fields, e.g. street_number2;
* other fields are emptied once saved, e.g. street_name and street_number are
False;
* both company and its partner records are now incorrect;
This is probably due to the unique inverse method introduced by the reverted
patch that sends only the updated value to the inverse method, leading to
other values being reset.
Original task ID 2068145
PR odoo/odoo#42701
X-original-commit: 3f4862ee8c9193719abd8e6dd647e6584f232103
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
Steps to reproduce the bug:
- Creante a vendor V with a lang in French
- Set lang English on your user U
- Log with U
- Create a lunch.order.line for V
- Click on Lunch: Order meals
Bug:
The email was sent in the lang of U instead of V.
opw:2155628
closesodoo/odoo#42543
X-original-commit: 8708ef16608dd8b6cdcad066e31f70f6262af205
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce the bug:
- Let's consider the current user U logged in company C
- Let's consider two operation types OT1 and OT2 with code = 'incoming' and warehouse_id.company_id = C
- Let's define OT2 as default value for field picking_type_id in model 'purchase.order'
- Try to create a new RFQ
Bug:
The default picking_type_id was OT1 instead of OT2
opw:2124083
closesodoo/odoo#41700
X-original-commit: d49abf3c8f21ccd56c12f9835520deaf715ffcc0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Tests about financial reports could be not determinist because the tests are made
using two companies having the same chart of accounts.
closesodoo/odoo#42226
Related: odoo/enterprise#6432
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Before this commit, trying to put a transaction in a state
where it was already in was causing an error.
For example: Putting a transaction in'Done' when it was
already in'Done' caused an error
'Only draft/authorized transaction can be posted.'
Now, we just log a note that the transaction is
already in the good state and pass over.
closesodoo/odoo#41701
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
In some cases, Stripe will return the result of a transaction with
a faulty HTTP Status (e.g. 4XX statuses) - not because the request
was malformed, but because the payment failed. It is a bit unfortunate
that Stripe would not differentiate between payment status and request
validity, but that's the state of things.
This commit ensures that such a response will be logged correctly, by
making the call to `raise_for_status` conditionnal on the response object's
status code and internal structure, forwarding the response's json to the
validation flow if the status is in the 4XX range and a `code` key is
found in the response, as described in https://stripe.com/docs/error-codes
While testing this fix, it became apparent that some error message
processing in the frontend was not correctly handled as well - instead
of purely rejecting the promise, a failed payment should still send its
payload to the backend, to allow the server to put the transaction in
the correct state according to the response.
Onchanges can be triggered after computes and therefore, we could have a line with an uom
but without product, leading to a conversion from "no uom" to the order line uom, which isn't
accepted.
closesodoo/odoo#42691
X-original-commit: 1bc9963cfc19a4bc5896a647423f81274936db00
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce:
-install purchase
-install inventory
-go to purchase > control > incomig products
-activate kanban view and group by picking
Previous behavior:
clicking create allows for quick creation and all cards are
draggable, which creates inconsistency on the moves
Current behavior:
quick creation is not allowed and kanban cards are not draggable
opw-2165106
closes https://github.com/odoo/odoo/issues/36043closesodoo/odoo#42683
X-original-commit: f0ba4c9278a8ab0ca051592790c6dbf3150a10d7
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Rev. bc131c0cfb aimed to handle the case of several
(conditional and exclusive) <label> tags for a same field.
The idea was to wrap those <label> tags into a div with
className 'o_td_label' (typically set by the framework), and
let the framework move it to the td wrapping the div.
However, it causes an css issue (only in community), as the
presence of two o_td_label classnames (one on the td, and
one on the div), produces two right borders.
This commit fixes the issue by removing the classname on
the div (we simply 'transfer' it to the td).
Closes#42589closesodoo/odoo#42667
X-original-commit: f71979a681d95d98db19a80feb59fdf684ec361f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the corrected test crashed when the current
date was before the arbitrary dates of the test
because the wrong exchange rate was taken
After this commit, the test passes
closesodoo/odoo#42671
X-original-commit: 5867e9bf0cc745d7b1b3dcf76bc94567e859cff7
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Issue
- Install Employee
- Settings > Enable skills management
- Go on employee form view
- In languages, click on add
- Quick create a skill & save
- Save the form
ValidationError "The skill %s and skill type %s doesn't match"
Cause
You should not quick create a skill, you should edit the skill
type, add your skill and then select it.
Solution
Disabling skill quick create because it's misleading
OPW-2163059
closesodoo/odoo#42642
X-original-commit: 29a37ef574726cf7616ed6237e56626ba3c380a5
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Hiral Bhavsar