- Activate: 'Order-Specific Routes' and 'Dropshipping'
- Create a stockable product in AVCO + AUTO
- Purchase the product at $10 and validate the receipt
=> One product @ $10 in stock
- Sell the product via dropshipping
- A PO is generated, change unit price to $20, validate
- Validate the picking
The product in stock has now a cost of $15, i.e. the dropship impacted
the cost of the product.
Now if the product in stock is sold, the product will go out at a cost
of $15. This will lead to a wrong accounting valuation (0 product in
stock with -$5 in stock).
opw-1922289
opw-1935272
opw-1937672
closesodoo/odoo#31786
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The widget handle was displayed on x2m fields in form views, even when
the field was readonly, which makes no sense.
It is now correctly hidden.
Fixes#30580
opw-1937833
closesodoo/odoo#31743
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In order to allow the user to ealisy retake the survey he just either passed
or failed (in case of scoring activated), a retry button is added not only
in case of failed scoring survey (like it was already the case)
but also for non scoring survey.
This button is also added in the review survey page, to get direct access to
retry the survey.
The rule is the following and apply to all survey types :
If not quizz passed (this will be always true for non scoring survey):
if is_attempts_limited
if attempts left
Add retry button
else
Add retry button
Task ID : 1950429
PR #31802
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
purpose: de88a727b2 introduced
a change in the sale order view. it reduced dramatically the size
of the 'terms and conditions' widget.
This commit set back easily readable dimensions
Task : 1950799
closesodoo/odoo#32129
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Purpose: clean mail.mail creation code and use standard mail creation or
template send_mail method. In those addons we ensure author and email_from
are set to maching values, leading to more consistent emails.
Related task ID 1965040
PR #32459
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose: clean mail.mail creation code and use standard mail creation or
template send_mail method.
In crm iap lead we can avoid custom mail creation by correctly using
send_mail method of mail template and its arguments.
Related task ID 1965040
PR #32459
Purpose: clean mail.mail creation code and use standard mail creation or
template send_mail method.
In calendar there was strange code creating an email based on a template
then updating some values on its mail.message record created through
inherits. It seems simpler to correctly set some specific email arguments
to MailTemplate.send_mail() method and avoid this kind of code construction.
Related task ID 1965040
PR #32459
Attachments when generating an email based on a template are done in two
steps, see notably [1]. However mail generation replaces attachments using
a 6 command. This means existing attachments given through email_values
are not correctly managed and this leads to invalid command given to the
m2m field.
This commit fixes that by correctly generating a list of commands, using
4 (add) for new attachments coming notably from reports linked to the template.
Related task ID 1965040
PR #32459
[1] https://github.com/odoo/odoo/commit/f789005c9a6c26322565a1af7cc4e57a60eab9f0
As a start_tour helper was added on the python side (PR #32316),
a javascript helper counterpart was needed as suggested on the PR.
closesodoo/odoo#32441
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
- Improved description of point of sale application
- Removed status from card like 'In Progress' and 'Unused'
- Click on top-right corner of POS kanban card, it shows 'Sessions' and 'Sales Orders', now it will shows 'Orders' and 'Sessions'. (for usability purpose).
- Improved Multi-Currencies wording same as invoicing
- Removed 'Advanced Currencies Setup' from settings(when clicking on 'Multi-Currencies').
- Improved list view label on 'Point of Sale'.
- Added 'PoS Product Categories' feature in 'Restrict Available Product Categories'.
- In PoS config setting, 'Pos Interface' string is put instead of 'Order Interface'.
- Filter and display issues were there when setting 'Currencies' from 'Multi-Currencies', now it is resolved.
- String 'PoS Product categories' is put instead of 'PoS Category', as it seems meaningful.
- 'Restrict Available Product Category' is ticked but any category is not selected (it means it is kept blank), then all categories are shown at POS screen.
- Allow to set default category from the available categories
- 'iface_start_categ_domain_ids' is removed because domain for 'iface_start_categ_id' is given directly in the model. So 'iface_start_categ_domain_ids' will not be required anymore.
This commit is related to task id: 1925458
closesodoo/odoo#30808
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
On a sale order, if all for product are services, we hide
the delivery related button ('add a shipping cost' and 'recompute delivery price')
Task : 1940491
closesodoo/odoo#32145
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
With this commit, `description_sale` is now editable in frontend.
We also display a clear placeholder to warn user that anything in this field
will be reflected on backend document (SO/Invoices).
task-1951231
closesodoo/odoo#32206
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, the syntax to start a tour was extremely verbose.
With this new method, it is possible to start a tour by just giving the
essential parameter: the tour name.
The full set of features from browser_js are kept by using **kwargs.
closesodoo/odoo#32316
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
This merge changes lot of small things in sale modules. The 3
main points are
- Sales Orders form view: reorganize fields for a better usability
and renaming labels
- Sale PDF report: renaming labels and titles, moving some report section
- Quotation Portal: improving style, moving section and renaming labels
Task-1920476
closesodoo/odoo#30550
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
In described Modules, there are some fields label like Unit of measure, Discount,
Ordered Quantity, etc... in views(list,form), report and portal, that are messy
and barely readable when lots of features are installed.
Purpose of the task is to shorter that all fields label to make clean view in
order to make it more readable without getting labels uselessly spread out on
several lines
Related to task #1933746Closes#31962
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Rename the attachment file name.
Restore the option : have the name of the customer who viewed the quotation on the email notification
TaskID: 1920476
closesodoo/odoo#30550
Small changes in quotation portal view:
* Reposition the 'Expiration Date'
* Added Incoterm info
* Added ":" after address
* Rename Details => Pricing
* Rename Optional Products => Options
* Remove "discount" in the column "discount" after the % In the
section "Options" add "10% discount" like in the printed report
* Add payment terms note
Purpose is to make it a little more beautiful and cleaner
for end user.
Task-1920476
Change capital letter "A" in Invoicing Address ..etc
Added space between address and "Quotation number"
Remove the time of the quotation date
Replace "expiration date" next to "quotation date"
Rename Optional Products to "Options" and place it above the terms and conditions.
TaskID: 1920476
closesodoo/odoo#30550
The list view of account.move.line is now editable (and grouped by
account.move by default).
Morever, when grouping by move, there are now action buttons in the list
view header.
Part of task 1915702
closesodoo/odoo#32337
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
By using proper BS4 classes for alert, so it looks better and it is more
compatible with themes.
Also removed the unused "Option not available".
closesodoo/odoo#32061
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Base issue: unnecessary inherit of composer on mail.message. Indeed there are
a lot of unused fields coming from mail.message as well as message specific
behavior (notify, check access, various business methods) not relevant for
composer.
Specifications
* remove inherit from mail.message;
* re-define used fields;
* ensure everything still works;
Commit linked to task ID 1907153 and PR #28464
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Mail composer does not support channels. Indeed as it can be used to post
a message or send an email it only supports partners. Previously field
channel_ids given to the composer was used only in website_forum. However
it is not used and therefore simplest way of solving it is to remove it.
Anyway allowing to have channels followers of forum tags and being notified
of new publications is probably more spammy than really necessary. Especially
that it never worked.
Commit linked to task ID 1907153 and PR #28464
Some counters are not up to date notably taking in to account community-only
and test-mail with enterprise only counters. Those are used notably when
developing to ease quick check of counters.
closesodoo/odoo#32370
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Task 1934667
1. That's the partner type (and not the payment type) that should define if a payment is a customer or a supplier payment :
a. When the partner type on the payment is "customer", the payment should be considered as a customer payment
(and thus be visible from the menu customer payments)
b. When the partner type on the payment is "supplier", the payment should be considered as a supplier payment
(and thus be visible from the menu supplier payments)
2. The PoS should only create customer payments (you never pay suppliers through the PoS)
The payment created should be with a partner type "Customer"
But the partner field can stay empty if the customer wasn't set on the PoS Order
3. When I change the payment type while creating a payment from scratch, it shouldn't change the partner type
Example : I'm creating a payment for a reimbursement, I'll create it from the customer payments menu (as I'm paying a customer), I'll tick the payment type "Send money"
I don't expect the partner type to change to vendor.
closesodoo/odoo#32201
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Removes the 'Show Reserved' option in operation type (PickingType).
Task #1944853closesodoo/odoo#31523
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
In case it's appropriate (using multilocation or lots/serial numbers)
the 'show detailed operations' option is active by default when a new
operations type is created.
Task #1944853
Before this commit iteration in a t-foreach containing null or
undefined values crashed because they have no attributes.
closesodoo/odoo#31828
Signed-off-by: Fabien Meghazi <amigrave@users.noreply.github.com>
- When creating a user from the "Grant Portal Access" wizard, the code
checks for duplicate users.
It does so by checking if there is a user with the same login as the
one we want to create.
The check is case sensitive which could lead to issues.
For example a mistyped email (with a uppercase somewhere) could fail
the duplicate user check.
Since emails are not case sensitive, we want the check to be case
insensitive too.
OPW-1932918
closesodoo/odoo#31818
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
This is related to issue #31549, fixing it in 10 since it's already a
minor issue here (importing 500 partners which all have the same parent,
on my system the import time goes from 2:30 to 2:00).
This is mostly a problem for such fields as `property_product_pricelist`
(added do the commercial fields list by `product`): since we're first
getting it then writing a field it depends on (updating the address,
which contains the country), the field gets invalidated for all records
on each record being imported, so if we're importing a bunch of partners
which all have the same parent (e.g. company employees)
`property_product_pricelist` is going to be re-computed for every
partner imported so far as well as the one parent we're interested in,
for every new partner we're creating.
The problem is much more prevalent with 12.0's batched creates as we're
first creating all the new partners then doing the updates, and thus for
each new partner we're computing `property_product_pricelist` for all
new partners and the one parent we're interested in, roughly doubling
the import time of a series of partners which all have the same parent.
closesodoo/odoo#31804
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When comparing product, there was already an exceptions that would not
list the attributes if they were only "create_variant=False" type.
But if we mix attribute create_variant False or not on a product, we
could get an error.
With this changeset, create_variant=False attribute are ignored also
when mixed with create_variant=True attributes.
opw-1946361
closes#31680
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This field is a non-sense. By using the same logic, it should be added
to any low level model.
Replace the check by a simple verification of presence of an XMLID.
A more generic opt-in solution should be integrated into ORM.
Partially revert commits 0db0e66e96 and
bbd64c22ab.
See #29257odoo/enterprise#3550closesodoo/odoo#31778
Signed-off-by: Christophe Simonis <chs@odoo.com>
Currently, user input lines of type ´datetime´ are not
correctly displayed in both situations:
1. not displayed at all in the survey result frontend page
2. the answered value is not displayed in the form view of
a user input line.
This commit fixes both issues
closesodoo/odoo#31815
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
Commit 98d0424 (merged in saas-12.1) fixed a Deprecated warning by using
`field_utils.parse.date` instead of relying on
moment to parse the date.
However, a datetime question type was added in saas-12.2.
When the fix commit was forward ported, the parsing of datetime
broke as `field_utils.parse.date` can't parse a datetime.
Fix: use `field_utils.parse.datetime` if `questiontype === 'datetime'`.
Also, defining `toJSON` method is no longer necessary because
it is already done in the field_utils methods.
The Widget's init function is synchronous.
The 'then' will execute after the end of the function so
self.group_portal_id will not be set immediately.
Also, RPC's in the init function is really not a good idea, it should be
putted in the willStart.
Original commit: https://github.com/odoo/odoo/commit/855c6dac25fccaf9312543022001ed0b360d6e13closesodoo/odoo#31508
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Which was basically creating n² account move lines.
If a POS session has 100 orders with each 10 lines,
100 * 100 * 10 account move lines were being created.
closesodoo/odoo#31736
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
`fast_counterpart_creation` creates new move lines.
The ORM doesn't know if these new move lines changed
or not the value of the field `journal_entry_ids` of each
of the bank statement lines, and for that reason
this field got invalidated from the cache at each iteration,
and the value was prefetched as soon as
`st_line.journal_entry_ids.ids` was asked.
Storing the value of this field for each line in the dict
`journal_entries` overcome this problem as we get the value
from this dict during the loop.
Of course, this relies on the fact the value of `journal_entry_ids`
doesn't change during the loop
Sequel of cc54194e13.
The mentioned fix only worked when the user was public.
The problem arises when calling the function `_get_fpos_by_region()`
in `sudo` without specifying the company and this happens, for instance,
in every `onchange_partner_*` function of a sale order.
We propose to add the `force_company` key in the context of the sale
order to ensure the right company when selecting the fiscal position.
closesodoo/odoo#31751
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Nicolas Martinelli