This commit removes the read access on slide.answer for all
users except website_publisher and admin
Task: #1947884
PR: #32083
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit fixes the amount of point gained in a quiz.
The amount of point displayed on the quiz was the number you
would gain on the next attempt instead of the actual amount you gained
when passing it. This was due to the usage of the wrong variable.
Task: #1947884
PR: #32083
Mostly a concern during bulk import of partners with parents.
First remove syncing extended fields, that seems completely
unnecessary since the street gets sync'd and will get split through the
normal process (updating the sub-fields), by also syncing the split
fields we're redundantly calling _set_steet and rewriting the address
we just sync'd.
Second if write()ing both the country and street, the override would
then go and re-write the street based on what had *just* been split
into sub-street fields, which could waste a lot of time during the
import post-process as address fields get moved back and forth between
parents and children leading to *lots* of writing both country and
address together, we're talking:
ncalls tottime percall cumtime percall filename:lineno(function)
10002/2 0.111 0.000 344.390 172.195 res_partner.py:181(write)
[...]
2 0.455 0.228 165.264 82.632 base_address_extended.py:41(_set_street)
My initial instinct was to just add the country_id to _set_street and
remove the write override but it would break
88ff6beb01: if the country alone is
updated on a partner, we do want to re-format the "unified" address
based on individual fields and the new country's format.
Note: it might be that the logic would be more sensible by inversing
the entire thing, such that the split fields are the proper
source (regular stored fields) and street is converted to a computed
field instead, but that'd be a larger model change. Seems like it'd
make more sense though, at least given what the modules attempts to
do (OTOH the module probably fails
https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/
in just about all the ways).
Should correctly handle / fallback to regular code when processing
non-stored partners.
Perf difference according to cprofile on my machine:
original python:
ncalls tottime percall cumtime percall filename:lineno(function)
1 0.134 0.134 205.380 205.380 res_partner.py:277(_compute_commercial_partner)
SQLized
1 0.118 0.118 67.239 67.239 res_partner.py:280(_compute_commercial_partner)
most of the time leftover seems to be in modified_draft
With profiling enabled, importing 10k partners, with all of them
having the same parent (though not with all of them having the same
is_company setting) lowers sync / post-process time from ~550s to
~330s.
Put it in an override to _load_records_create so it's only active for
imports (which is the original report & test case), use a context key
to avoid going the post-processing work in create.
- Create 2 companies A & B
- For a product P, create a supplier info for each company using the
same partner, with a different price and delay.
- Order the supplier so that the one for A has a higher priority than
the one for B.
- Create a reordering rule for P in company B.
- Run the scheduler as admin (e.g. thanks to the cron).
The price taken is the price for company A instead of B.
`_select_seller` is not company-aware, therefore the first matching
supplier is chosen.
opw-1959263
closesodoo/odoo#32328
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Go to Sales > Configuration > Settings
- Enable "Multiple Sales Prices per Product" and select option "Prices
computed from formulas (discounts, margins, roundings)"
- Go to Sales > Catalog / Pricelists
- Select "Public Pricelist" and set "Discount Policy: Show public price
& discount to the customer"
- Go to the eCommerce, buy "iPad Retina Display" which as a 20 %
discount
In the corresponding SO, the discount appears to be zero, and the
discount is included in the price unit. However, adding the product
directly to the SO in the backend displays the discount as expected.
There should not be a difference in behavior between the eCommerce and
the backend.
Fixes#31337
opw-1943989
closesodoo/odoo#31965
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Activate multi-company, but do not share contact book.
- Create 2 companies A & B
- Create a partner named 'PartnerA' in company A
- Switch to company B
- Import a bank statement with partner name set as 'PartnerA' (use the
bank statement template if necessary)
- Reconcile the entries
An `AccessError` is raised.
The partner suggestion doesn't take into account the record rules,
therefore it might happen that the user doesn't have access to it.
opw-1958711
closesodoo/odoo#32239
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In case two modules are using the same local name for their external identifier,
a conflict may occure.
e.g. the templates
- l10n_generic_coa.a_salary_expense
- l10n_be.a_salary_expense
will generate
- l10n_generic_coa.1_a_salary_expense
- l10n_be.2_a_salary_expense
As the previous search for in_xml_ids was using a domain
('name', '=', 'a_salary_expense')
both records were returned, making in_ids to have one more record than out_ids
Followup of review made at odoo/odoo#31510closesodoo/odoo#31604
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When creating a record from a calendar view,
the default form view is always used when using the popup mode,
ignoring the `form_view_id` attribute of the <calendar/> tag.
After this commit, the `form_view_id` is no longer ignored.
closesodoo/odoo#32379
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
- Set your fiscal year end date to 28th February
- Run the P&L a year before a leap year, e.g. anytime between March 1st
and December 31st 2019.
- Select 'Last Financial Year'
The dates are set from 2019-03-01 to 2019-02-28.
There are actually 2 bugs. The one solved here is the following
inconsistency:
```
current_date = type(date)(2019, 4, 3)
date_utils.get_fiscal_year(current_date, day=28, month=2)
'date_from': datetime.date(2019, 3, 1), 'date_to': datetime.date(2020, 2, 28)
current_date = type(date)(2020, 2, 28)
date_utils.get_fiscal_year(current_date, day=28, month=2)
{'date_from': datetime.date(2019, 3, 1), 'date_to': datetime.date(2020, 2, 29)}
```
Both should return `'date_to': datetime.date(2020, 2, 29)`. This implies
that the period is recognized as `custom`, which is affected by the bug
solved in PR https://github.com/odoo/enterprise/pull/4006
opw-1949628
closesodoo/odoo#32366
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce:
- Create a storable product P with a vendor V and a purchase price = 100€
- Set the category of the prodcut to automated and AVCO and set a price diff account on it
- Create PO for V with 10 P with a price_unit = 110€
- Confirm the PO and deliver 7 P with no backorder
- Change the ordered quantity of P to 9 on PO (and the unit_price will be set to 100€)
- Go on the delivery order and deliver 2 remainig P
- Create the invoice and validate it
Bug:
The amount due on the invoice was 900.02€ instead of 900.00€
PS: The debit and credit of an aml are computed with the price (defined in function
_anglo_saxon_purchase_move_lines) with the function _convert_prepared_anglosaxon_line
defined on model account.invoice. So rounding the price unit after the computation
of the price allows to keep the same total as the one computed for the PO.
opw:1951465
closesodoo/odoo#32345
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When we go on a failed mail.mail and do "Retry" -> "Send Now", if there
is an existing notification that is not to the current user, we may get
an error or get the email in error.
This is because on a notification only:
- the superuser
- the targetted user of the notification
have write permission by default in Odoo.
So with existing notifications resending (by the mail.mail views, the
alternative mail.resend.message wizard works as expected) only worked
if they were current user's notifications or if user is superuser.
opw-1957730
closes#32346
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Test was relying on qty_to_consume getting saved when the produce form
is saved, a behaviour of the SSF which diverged from the actual
client.
After fixing the SSF to behave more in-line with the actual
client (don't save o2m sub-fields unless they're flagged as
force_save) the test is now visibly broken.
Fix it so qty_done is properly updated during wizard configuration /
edition instead of updating the in-database object directly.
closesodoo/odoo#32047
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The SSF would correctly filter out readonly fields when saving a
toplevel form, however it could not remove readonly values when saving
o2m pseudo-records to the parent form (as these would be expected to
remain available for reading upon the next edition and whatnot), so
these values would get sent in 0/1 commands.
Filter out these fields during the parent / toplevel save call.
Complexity notes:
* evaluating readonly modifiers requires the entire record, so
unchanged fields still have to be written back to the parent form
and be filtered out when *it* is set up for save, an alternative
would be to store the `changed` and `readonly` flags alongside the
record dict, and have the post-process only override the
pre-computed readonly flag using force_save
* had to fix a test to match the new behaviour, the post-edition
states turns out to be in line with the client's behaviour (or how
it looks anyway)
Fixes#32019
The extra setup probably affects any o2m whose edition view itself
contains an o2m, but most likely to blow up entirely on models with
some sort of tree structure (parent/child relationship): the SSF
eagerly loads and setups the o2m's view, and the o2m's o2m's, ... ad
infinitam.
A better / cleaner fix would be to set up the subview on-demand (and
possibly cache it), but the rest of the o2m stuff is unlikely to work
correctly recursively so just don't recurse the o2m view setup at all
for now.
fixes#31458
-replaced domain with context in workorder view. user cannot work on
done or canceled workorder.
-added a default, removable filter to show orders of current workcenter
from dashboard.
This commit is related to task id: 1911218
Co-Authored-By: Hetal Dhanak <hdh-odoo@users.noreply.github.com>
closesodoo/odoo#29492
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Somehow, when a sales order is confirmed, its confirmation date might not be set (or it is
possible to remove it). This makes no sense as we expect it to be set when the SO is confirmed.
This commit adds an SQL constraint to ensure the confirmation date is required when the SO is
confirmed or done.
To populate this column, the confirmation can be deduced from the mail.message, with the confirmed
subtype.
Task-1930506
closesodoo/odoo#33230
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
If timesheets are recorded on tasks that aren't linked to any Sales
Order, the user can assign a SOL (in batch) later on by going to the
Action > Assign Sale Order Item. Since the introduction of FSM, the
user can directly create Sales Orders from the Project Overview and
from Tasks. This makes the "Assign Sale Order Item" action redundant.
This commit removes this action.
Task-1968074
closesodoo/odoo#32696
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
-customers were misunderstanding the concept of "no gap" sequence
implementation hence updated the tooltip of the same to make it more useful and
clearer.
Task-1973967
closesodoo/odoo#33017
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Comparing float is a sensitive matter. Odoo creates specific tools
to manipulate float values. This commit makes the reinvoicing flow use
those tools to avoid rounding mistakes, ....
Task-1962608
closesodoo/odoo#33229
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
Rev. odoo/odoo@5dc971b introduced a `description` attribute on AbstractField.
Sadly, the attribute was already used for something else (in `handle`
and a widget in asset, to hide the column name). So the widget new
description is now displayed in the list header (instead of the field
name).
A new attribute `noLabel` has been now added on AbstractField (currently
only used in list) to fill the same purpose as the previous `description`.
Task 1981757closesodoo/odoo#33060
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
A traceback occured when displaying the tooltip (only visible in debug) on a list
view header if the field had a `widget` attribute (introduced in rev. odoo/odoo@5dc971b).
The issue here was linked to the fact that a widget is not always rendered in list view
(compared to form view) so the `Widget` property in the attributes was not there.
Task 1981757
Before this commit, there was no space between:
- Install button and Upgrade button.
- Uninstall button and Upgrade button.
After this commit, margin will be added to all the buttons for proper layout.
Task ID: #1937131closesodoo/odoo#30829
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Before this commit, it was allowed to add empty lines while adding a member in channel.
After this commit, it'll not be allowed to add empty lines as partner_id is required.
Task-1973972
closes#32958
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
As it's easy to forgot user's password and if user do,
user currently have no way to reset it if user didn't activate
the settings to enable the Reset Password.
so enable this options by default to avoid people getting blocked
because they forgot their password.
task-1925281
closesodoo/odoo#30391
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
This commit extracts the logic of the selection of the default
value for search panel categories into a private function
so it can be hooked in other modules.
task: #1959112closesodoo/odoo#32448
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
This prevent the uninstallation of all payment provider through the
NOT NULL constraint. There is no reason for this field to be explicitely
required - it will fail if the template is wrong anyway.
closesodoo/odoo#33170
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Rev. a3489be33 removed this feature to fix a bug (when the single
line many2one, e.g. a product, is too long and displayed over
several lines). However, we (fp) still want this for res_partner
many2ones with show_adress.
This rev. re-introduced the feature without re-introducing the bug.
closesodoo/odoo#33139
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
This commit introduces the Alipay payment provider, a popular acquirer
in the Chinese market.
There are 2 possible ways to use this acquirer:
- express checkout mode (only available for merchants located in CN)
- standard checkout mode (availabe for foreign merchants)
Note that this provider does not support server-to-server payments,
tokenization or any other bells and whistles besides fees. There are no
specific behaviours related to this acquirer, it behaves like most 'form
based' payment acquirers with a form submission, s2s notification from
the provider as well as redirect in case the s2s did not reach the
server in time.
closesodoo/odoo#21855
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
purpose of this commit is to schedule an activity exception on delivery picking
when user change address of the SO, to notify user that
sales order address is changed.
Task-1888829
closesodoo/odoo#28191
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Tag name should be "Need Assistance" instead of "NeedAssistance".
Task-1891795
closesodoo/odoo#32146
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
The activity view has been greatly improved to allow to customize it
more easily. It works quite similarly to the kanban view, defining
`<field>` tags at the top and using these fields in the `<template>`
section. The template name used to define the activity cards is
`activity-box`.
Other features have also been added (see each commit for more information).
closesodoo/odoo#29271
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
The activity view has been added on multiple models (invoice, fleet
contract, vehicles, leads, employee, contract, expense, expense sheet,
leave, leave allocation, applicant, partner, product, task, purchase
order, sale order) to ease the creation and the management of
related actvities.
Task 1894990
The activity view has been refactored and improved so the qunit test
suite needed to be adapted.
More tests have also been added to test new features (progressbar,
schedule an activity, etc.) and the method 'get_activity' has been
correctly mocked (the result was previously hardcoded).
Task 1894990
At the top of each column of the activity view, a progress bar is now
displayed below the activity type name based on activities scheduled.
Note that the progress bar widget is an extension of the kanban progress
bar as both have a very similar behavior.
Task 1894990
Just like other views (form, list, kanban, etc.) CRUD operations (create,
delete and edit) are now set as attributes on the activity node based on
the user access rights.
Task 1894990
In the activity view footer, it's now possible to create a new record
(and an associated activity). When clicking on the link, a 'SelectCreate'
dialog is opened and the activity is created when selecting a record.
Task 1894990
qmo-odoo