The POS recomputes order lines when the pricelist changes. This is
different from the sale app on purpose: in a usual POS flow the customer
and thus pricelist is selected after taking the order.
But users commonly use a 'Miscellaneous' product when they are selling
something that is not in their POS system. The user can select this
product and manually set the price. When now a customer is
selected (even if the pricelist has not changed) these miscellaneous
order lines get recomputed. So now the cashier is forced to input
these prices again.
To avoid this we keep track of lines that have had their price changed
through the UI and we don't update them.
opw-817353
Purpose of this merge is to ease future tasks improving activity
configuration, generation and tweak of various mail related data and
features. It contains
* add menus in hr_recruitment and project to configure activity types;
* split data in various main applications to have mail-related data in
their own file;
Future tasks will be about generating activities, improving the mail
activity mixin and removing some subtypes. This merge is related to the
task 60962. #Closes #23232 .
When validating a vendor bill, we want the product
with expense policy set to be reinvoice on the open
sales order matching the analytic account of the invoice
line. Applying the same mecanism for customer invoice
does not make sense, as we might confirm a SO and validate
its invoice, we don't want a new SO line to appear (avoid
loop).
Unfortunately, since a long time, this is possible in Odoo,
and really make no sense. We should only take negative
analytic lines (coming from vendor bills and expense, not
the customer invoice) into account for adding SO line.
This commit correct this problem to avoid having
many null SO line created on customer invoice validation.
All test cases are correctly written, but there was no
check to prevent this mecanism to be apply on customer
invoice.
It is simpler to have data split by main model or application like we
already do for models and views. It allows to easily have an overview
of data a module holds.
As we will work on mail related data like adding activities or tweaking
subtypes and templates, having them all in a single file and not lost
between other data helps finding and working with it.
This commit only moves code. No functional change should occur.
It is simpler to have data split by main model or application like we
already do for models and views. It allows to easily have an overview
of data a module holds.
As we will work on mail related data like adding activities or tweaking
subtypes and templates, having them all in a single file and not lost
between other data helps finding and working with it.
This commit only moves code. No functional change should occur.
It is simpler to have data split by main model or application like we
already do for models and views. It allows to easily have an overview
of data a module holds.
As we will work on mail related data like adding activities or tweaking
subtypes and templates, having them all in a single file and not lost
between other data helps finding and working with it.
This commit only moves code. No functional change should occur.
It is simpler to have data split by main model or application like we
already do for models and views. It allows to easily have an overview
of data a module holds.
As we will work on mail related data like adding activities or tweaking
subtypes and templates, having them all in a single file and not lost
between other data helps finding and working with it.
This commit only moves code. No functional change should occur.
Purpose of this commit is to ease project managers in their daily job
organization by ensuring that newly created activities in project
configuration are by default associated to tasks, and not global.
Activity types actions and views are moved in their own file in order
to match the guidelines.
Purpose is to ease HR recruitment people in their daily job organization
by allowing to tune activity types. A menu is added in configuration to
access activity types. Those are by default associated to the applicant
models.
Purpose
=======
The warrant cost formulae has been modified at 5d22170.
Instead of using the (remaining) warrant costs formulae, use the corresponding field instead.
Issue:
domain="[('date','=',time.strftime('%%Y-%%m-%%d'))]"
is converted into a domain equal [('date','=','%2017-%12-%12')]
instead of [('date','=','2017-12-12')]
In Calendar views, the displayed period should be written in the
breadcrumbs (e.g. in month mode, '(February 2017)'). This has been
broken by rev. 7b6056a0b5.
Odoo 11 comes with unified features for Project Tasks and Project
Issues. Specifically, issues were retro-fitted into tasks, and saw their
specific features added to the features of tasks.
During this refactoring, the portal controller for issues was superseded
by a unified portal controller for tasks, via
623ea43268
One case was lost in the process: portal visibility of
tasks/issues/things that are individually followed by customers, without
the customer following the project itself.
This is important for `transversal` projects, such as a "Helpdesk"
project common to all customers, where each customer only sees their own
issues.
This commit restores the feature, previously added to issues by
1cc8252a95
Note: this clearly requires a proper regression test, to be added soon.
Some label or name for new demo data are not clean.
This commit imrpoves them by:
- rewritting clean descirption for timesheets
- set negative amount for expenses analytic lines
When sending notification from the frontend, if a template is rendered
for it and the user has the group "website.group_website_publisher" he
will get inherit_branding adding on elements things like:
data-oe-id="42" data-oe-model="ir.ui.view" data-oe-field="arch"
but the chatter system has feature automatically redirecting an element
that have attribute "data-oe-id": this caused for example that a
link notification towards the forum would instead be redirecting to
editing the view of the notification.
This fix distinguish the inherit_branding in the chatter feature and
ignore them.
opw-813333
closes#23225
If the activity had no summary the messages has a : leading to nothing
which is not very nice. If there is no summary, only display the "done
by" message followed directly by the feedback.
- Enable multi-company: without sharing products and partners
- Create 2 companies (company1 and company2)
- Create 2 users one for each company
- Create inventory transaction (receipt) by user1 in company1
- Create inventory transaction (receipt) by user2 in company2
- Using user2 run inventory valuation report with 'At a specific date'
option.
You got read access error for product.product.
This is due to commit 5c5098f740. We should apply the `ir.rules` to
the query.
opw-816663
- Create a custom field
Field Type: monetary
Tracking: Always
- Install any module
A crash occurs in `_instanciate_attrs` since `attrs` is `None`.
In some special cases, the instanciation of the attrs of a field is
delayed at the very end of the setup. For example, in case of a Many2one
for which the comodel is not yet loaded.
Therefore the override of the method should take this case into account.
Closes#22922
opw-815185
The domain is add in the view from the python field description.
Issue:
In expense go in "to Approve" > "Expense Reports to Approve"
Create a new expense sheet by clicking create
Add an expense to the sheet
Click create in the bottom left
result: Uncaught Error: Unknown field state in domain
Before this commit:
1. When enabling 'List View of Variants' on a product page, it would not
replace the variant normal view as it should since the code being replaced
is included in the code replacing it.
2.The badge specifying the price difference between the variance and the
product base price would be calculated by taking the price_extra of the
variance attribute and converting it in the user currency which was not
correct if a pricelist was set on the product variant because the price diff
would then be (the variant price set on the pricelist) - (product base price)
Note: this is about the 'List View of Variants' mode, not the normal mode
which list variant attribute and not variant itself
3. The strikethrough amount was not in the user currency
Step to reproduce:
- Enable variants & pricelists
- Enable multi-currency and activate 'COP' as second currency (you may want
to change the currency symbol on edit mode since it is also '$')
- Go to iPad Retina Display product page in shop
- Enable 'List View of Variants' in 'Customize'
- Both Variants selection mode are visible (bug 1)
- The third variant shows '+$ 50.40' which is the diff between the
strikethrough prices (in fact the sum of the price_extra of the product
variant attributes, +50,40 on the 32GO attribute in this case)
It should show '+$ 40.32' since the price change from $600 to $640.32.
This is bug n°2
- Change Public Pricelist currency from USD to COP
- Back on iPad page, change between the 3 product variants, you will see
the $ price strikedthrough instead of the COP one:
Strikedthrough: 750 (it should be 1 714 491,47)
Price: 1 371 593,17
This is bug 3
- You can notice the bug n°2 being more visible since it shows
'+$ 115 213,83' instead of '+ 92 171.07'
- Remove the iPad Retina from Public Pricelist and add iPad Retina 32Go
variant to it with a fix price of $1 000 000.
- '32Gb, 2.4GHz, White' variant cost $1 000 000 but shows '+ 115 213.83'
instead of '- 714 491.47' since the base price of Retina is
'1 714 491.47'.
- You can play with the pricelist price for this variant up and down, the
diff price shown in the badge will always be 115 213.83 since it will
always calculate it by summing all the variant's attribute price_extra
and then converting it to the user currency.
This closes#14094, closes#22553
When creating an extra move, the price_unit field was not copied. It is
normal since the field is copy=False following rev[0].
But there was a side effect: let's say you order 1 product @ $10 and you
receive 5. The received quantity field on the purchase order line is
correctly set to 5 and the valuation inside the stock is correctly set
at $50, but on the picking there is one move line of 5 and a move a 4
and of 1, instead of one of 5. Note that in v10, the pack operation
would be split between the original move and the extra move, but in our
case the extra move is merged back in the original move, so we don't
need to split the move line. The split mechanism is there only when
working with moves without picking[1].
The issue here is that the moves are not merged because they do not have
the same price unit (5 and 0). We thus copy the unit price when creating
the extra move.
When creating a backorder, the price_unit field wasn't copied either.
It's not important when working with the classic flows (the link to
purchase_line_id is kept), but to be consistent we also copy it.
[0] https://github.com/odoo/odoo/commit/a4740861d3fdbecc8b1171b7d2072697e8a36258
[1] https://github.com/odoo/odoo/commit/561b3461a020021d911999cb41154f158b069a1d
Currently if get_formview_id does not return a specific view id the
mail/view controller produces an url with view_id=False. Due to some
unknown reason it is not taken into account as False but as the
string False since some time. It generates a traceback and prevent
people from using the mail/view controller.
While finding why it seems to have changed we can avoid the issue by
setting the view_id only if set. It has no impact on the redirection
has the default for view is loaded as intended.
A new notif_layout parameter has been introduced at 304e6cf90b. However it is
not correctly propagated to sub-calls when redirecting message_post
using context and sub-model.
Notification template has been converted into QWeb at commit 0f301bec25.
A variable renaming has not been correctly propagated, leading to
tracking values not being displayed in notification emails. This
commit fixes that.
Joren Van Onder