This commit corrects erroneous instructions in the documentation page for the installation of Odoo.
Additionally, the following changes are made:
- Add new instructions where the steps were not clear or complete enough.
- Replace some installation flows for an easier onboarding.
- Rework some parts of the page structure and display.
- Add a "running odoo" section for Mac OS.
- Fix display error in views.rst
task-2072822
closesodoo/odoo#42900
X-original-commit: 82471da5d63f07796c6df1639aa30cc4894d5891
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
The constraint view in Odoo has no good quick search options to filter/group and find
specific constraints easily.
This commits allows you to easily group and search for the most used values of
constraints. This will make the finding of constraints easier for functional people.
closesodoo/odoo#41288
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Steps to reproduce:
- install sales, website, ecommerce
- go into debug mode and open your browser's console
- debug menu > start tour > shop
Previous behavior:
tour does not find trigger for the first step
Current behavior:
tour starts properly
opw-2126704
closesodoo/odoo#42870
X-original-commit: 7e0da0b9cd2c8fc22d3fd3125b48102992bf3479
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Let's assume a many2many_checkboxes widget in a form view with a
dynamic domain (depending on another field in the view). At first
rendering, the widget contains a checkbox for each value matching
the domain.
Before this rev., if the user changed the value of the field used
in the domain, the many2many_checkboxes wasn't redrawn, so it still
displayed the values matching the previous version of the domain.
Closes#38509Closes#40173closesodoo/odoo#42867
X-original-commit: 1ace56f9a8cb56fb39235468dd13447bcbbee40a
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Themes image would not be shown correctly in the theme selection if the
`website` module was installed in CLI.
Indeed, the code supposed to load the theme images was done in the kanban view
during theme selection after installing module through apps screen.
Now, this code is encapsulated and called in post_init hook of website.
This was also needed for an improvement on `test_themes` module, see
https://github.com/odoo/design-themes/pull/195.
closesodoo/odoo#42206
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Steps to reproduce:
Create one product with FIFO and automatic inventory valuation.
Purchase product with 10 quantity and cost price 100 and mark shipment as done.
Add landed cost for done incoming shipment with 2 cost lines
E.g. 1. Freight Charges - 100
2. Duty and Charges - 50
So ideally after first outgoing shipment total cost should get updated in product is
(1000 + 100 + 50) / 10 which is 115
The issue is that we increment `remaining_value` on the wrong layer.
Fixes#41923
task-2167659
closesodoo/odoo#42871
X-original-commit: 8b89a5e4a85071055bc152b11cf150e62a5c5211
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
PURPOSE
Remove partner_autocomplete_address_extended and ensure base_address_extended
effectively works.
SPECIFICATIONS
Commits a6e1eb9 and 8a1815b added among a lot of other things
a bridge module between ``partner_autocomplete`` and ``base_address_extended``.
It is used only to redefine the ``_split_street_with_params`` method from
``base_address_extended``. This method is used to find street name, number and
number2 from an address, given a format coming from the country.
However the override completely fucks up the original method purpose and uses
an hardcoded regex coming out of the blue. Parameters like country format is
not taken into account which is annoying when trying to parse country dependent
data.
Tests from ``base_address_extended`` crash completely when used with the
``partner_autocomplete_address_extended`` implementation.
Considering the original complete specifications from commits
"""
For Name field or M2O, gives a list of companies
Data comes from Odoo IAP Service
"""
Or specs found in the original task ID 1867818 pad
"""
If Extended Address module is installed, the street number should be correctly
splitted Or the complete address is put in street2 if impossible to parse
"""
We think that this implementation is broken by design. Indeed there is no
mention of street2 anywhere in the code, and this implementation ensure street
will never be correctly split. We therefore remove it completely.
In this merge we also
* clean and improve tests in base_address_extended. Purpose is to make tests
easier to understand and more data oriented. Tests about company / partner
address fields are added to ensure coherency;
* reorganize python code of base_address_extended according to guidelines;
* rename compute / inverse methods of base_address_extended;
* remove dead code from base partner model;
See sub commits for more details.
LINKS
Task ID 2158302
PR #42678
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Commits a6e1eb9f0a and 8a1815b31e added among a lot of other things
a bridge module between ``partner_autocomplete`` and ``base_address_extended``.
It is used only to redefine the ``_split_street_with_params`` method from
``base_address_extended``. This method is used to find street name, number and
number2 from an address, given a format coming from the country.
However the override completely fucks up the original method purpose and uses
an hardcoded regex coming out of the blue. Parameters like country format is
not taken into account which is annoying when trying to parse country dependent
data.
Tests from ``base_address_extended`` crash completely when used with the
``partner_autocomplete_address_extended`` implementation.
Considering the original complete specifications from commits
"""
For Name field or M2O, gives a list of companies
Data comes from Odoo IAP Service
"""
Or specs found in the original task ID 1867818 pad
"""
If Extended Address module is installed, the street number should be correctly
splitted Or the complete address is put in street2 if impossible to parse
"""
we think that this implementation is broken by design. Indeed there is no
mention of street2 anywhere in the code, and this implementation ensure street
will never be correctly split. We therefore remove it completely.
Task ID 2158302
PR odoo/odoo#42678
``_split_street_with_params`` method is defined in base, on partner model. It
is redefined in ``base_address_extended`` without calling super. Only that
module use it. That means that the base implementation is not used anywhere
in the codebase, leading to dead code. Let us remove that method.
Task ID 2158302
PR odoo/odoo#42678
Purpose is to make code follow guidelines so that we understand that
some methods are used for computed stored inverse fields.
Task ID 2158302
PR odoo/odoo#42678
Purpose is to reorganize code according to guidelines and split the main
badly named python file, to understand that 3 models are impacted: res.company,
res.country and res.partner.
Task ID 2158302
PR odoo/odoo#42678
Purpose is to make tests easier to understand and more data oriented. We
now understand more clearly what is an input and what is expected.
Tests about company / partner address fields are added to ensure coherency.
Task ID 2158302
PR odoo/odoo#42678
Currently when writing on street field of company model, its sub-fields
(notably street_name, street_number and street_number2) are not correctly
computed again in cache.
Indeed address sub fields have no direct trigger as it depends on its
partner_id and its partner_id children (see ``res_partner.address_get()`` and
``res_company._compute_address()``).
When writing on address fields from the company record, we then invalidate
all address fields cache in order to force their computation.
This commit adds a new tool method giving the list of fields coming from the
address partner to copy upon the company.
Task ID 2158302
PR #42678
before this commit when we installed website_sale and event_sale
module. it will display blank hole before Events group because
'email_template_and_project' group is define in
product/product_views.xml as invisible.
So fix this issue by moving this group into
product_template_email/product_view.xml and also rename the group
as email_template because this group is not related with project.
Also keep sale group empty in 'sales' page so other views updated to
make compatible with new group changes.
To keep groups in ordered, set the priority in view.
task-2150643
closes: #41308
Remove "Time Off" permission from a normal user (i.e. Marc Demo)
Login in as the user, go to Time Off > Managers (Time Off) > Create
Switch user.
Traceback will popup. This is caused by the computed field function
acquiring empty fields on change so the date_from will be False
opw-2166477
closesodoo/odoo#42859
X-original-commit: 57a6e8be9eb6ff31cb1edb7878f8c5dc913df8ec
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Make sure `to_date` is not `False` before comparing.
opw-2165860
closesodoo/odoo#42855
X-original-commit: dbb478507791957e3329d68cfb68dd4f1fab4b70
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When you create a new bank account from an account.move there is a very high chance that you're creating the bank account for this specific vendor. As we can create a bank account from the account.move we can directly set the vendor (account holder) if there is one set
closesodoo/odoo#42788
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
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>
Antoine Vandevenne (anv)