What matters in sales reporting is the confirmation
date (signature, payment, etc), not the creation date.
All the sales reporting is based on order date
(= creation date). Most people need the confirmation
date (to grant commissions, etc.)
Purpose:
========
When you start designing a page, you get a weird empty page
it was better in v8 with a default message prompting the user to drop a snippet
Specification:
==============
When a user starts designing a page he/she should get a default message prompting to drop a snippet (like we had it in v8).
[The drag&drop icon must be adapted: now snippets stand in the left side (and not in the upper part)]
Purpose
=======
Create an opportunity
Fill in the campaign, medium and source
Create a quotation from this opportunity
The fields campaign, medium and source on the quotation are empty.
-> they should be populated from the opport.
Specification
=============
Campaign, meduim, source data should be passed to quoation when create quotation from oppor
Refine the priorities of ir.values entries to make the result
deterministic in the presence of multiple matching default
values. We now give the priority to company-specific defaults,
before global defaults.
Before this change, the default value would be random when
both a per-company and global default value existed for the same
field (with no per-user default).
The priorities are now defined as follows (smaller number = higher prio):
1. Per-user default (user_id is set, company_id is set)
2. Per-user global default (user_id is set, company_id not set)
3. Per-company default (user_id not set, company_id set)
4. Global defaults (user_id not set, company_id not set)
The final "id" order spec ensures that the order is total.
Also added the corresponding regression test.
Closes#16038
When setting an activity as done in chatter users now have the possibility
to add a feedback. This feedback is added in the generated message that
already contains the activity name and note.
Moreover users now can also immediately schedule a next activity. This is
very useful for chained activities and speeds up activities use.
Portal user had too many access right on
sensitive documents in this modules. Some
ir.rule were missing, and some model access
were useless.
This commit clean all access right: ir.rule,
ir.model.access and remove useless check in
python code.
Also, some tests were added to check access
rights.
Portal has access (read only) to partner, pricelist,
taxes, ... These access were given to display informations
on portal pages. Since, these are not very secure, we
remove the access right.
Some modifications are required to make the portal work again :
- 'sudo' business document before rendering templates. ir.rule
are still apply to filter the documents do display.
For instance, SO total amount is computed using account.tax.
- a related field has been added on SO line to allow portal user
to see the image of the ordered product (on SO frontend view)
- a new controller is created to display invoice PDF (as 'sudo'),
since the rendering of this document required read access to
taxes, payment terms, ...
PO are now available in customer portal. It follows the same
convention as the rest of exposed documents (list, pager, form,
filters, ...)
To insert it after the SO menu item, some ordering was required.
Also, rename 'Orders' into 'Sales Orders' to avoid confusion
with 'Purchase Orders'.
This commit impact website_portal, website_portal_sale,
website_project, website_project_issue, and website_crm_partner_assign.
The idea is to hide menu items and dashboard entry in customer
portal when there no document available. Only Sales Orders and
Opportunities are always displayed to avoid empty dashboard.
Also, resequence menu items to be more consistent and to prepare
to insert more items in the future.
When you add a sale order line, odoo checks the available quantity
through all warehouse and if you add more than available, you get a
warning.
We improved this warning, by checking the quantity in the warehouse set
on the sale order, and if the quantity available in this warehouse is
too low, we warn the user with the quantity available in this warehouse
and in all other warehouses.
Currently when the salesman clicks on 'Preview' button of quotation it
is set as 'Viewed by Customer'. This commit improves this behavior by
ensuring it is triggered only by shared users.
This commit links the alias security and the channel configuration.
Indeed private or group-based channels should always have a restricted
alias. Moreover this alias should check channel members instead of
channel followers, as a channel has members and should not have followers.
This implies a small refactoring of the alias check in the mailgateway.
Code is extracted and moved on alias.mixin class, allowing to tune the
behavior through inheritance.
Otherwise by default their alias are public. This makes no sense for
private groups to have by default public aliases.
Field is set as invisible on the view because it makes sense to configure
only the channel and not details of its alias. Anyway it is always
possible to tweak the alias configuration under Technical menu.
This commit makes channel use 'followers' based alias security use members
instead. Indeed channels do not use followers anymore. Instead channels
have members, and alias security of followers should use members instead.
Currently check of alias security is directly embedded in mail.thread
routing method. In this commit we move this check in the mail.alias.mixin
class itself. Doing this allows models to extend or improve the behavior
depending on how inheriting models use aliases.
Currently channel model manually defines alias and inherits instead of
using the alias.mixin. This commit proposes to use alias feature through
the mixin to have a standard behavior.
Using a m2m to partners does not allow a real management of members
because it allows to create partners, and require access rights on
partner model. Instead it now uses the o2m to channel members
allowing creation, update and removal of members without having
to work on partner records.
This commit remove the portal module.
- depending module (portal_stock, portal_gamification) are
removed. Their features are now managed by their parent
module (mainly access rights)
- portal group and user are moevd to base
- wizard to convert partner into portal user is moved into
website_portal, which is the user portal module now.
The webclient is now forbidden for portal user since there is nothing
to expose for such user.
Some cleaning has been done in survey and rating_project.
About a `sudo` on ir.ui.menu, this commit (3649b7f359) removed it,
this commit (3d0cc2d6d2) re-added it.
Since portal user can not go on /web anymore, I think portal does not need to read ir.ui.menu.
Here some news scenario:
- if website is not installed, portal can log in, but will be redirected to login page
with an error message 'only employee can access'. Indeed, there is no page to display for
such user.
- if website is installed, but not website_portal, portal user can log in and will be
redirected to homepage. If he tries to manually access to /web, he will be redirect to
login page with access error (even if he will still be logged).
- if website_portal is installed, the portal user can fully enjoy its features.
All portal features were moved into base
and website_portal, portal module is obsolete.
This commit remove its code, and modify the modules
dependencies accordingly. website_portal now depends
on auth_signup.
The goal is to prepare the removal of
'portal' module.
- demo portal user is moved into base
- 'is_portal' field on res.group too
- remaining security rule are moved to base too
- mail template is moved to website_portal
The goal is to prepare the removal of
'portal' module.
Converting a partner into a portal user,
though the wizard is moved in website_portal.
'base' will manage portal user and group, but if
website_portal is not installed, there is nothing
to display for portal user.
The goal is to prepare the removal of
'portal' module.
Since this module only provides access rules and
rights, those ones are moved directly into its
parent module (aka 'stock').
Since no module depends on it, we can remove it
without problem.
The goal is to prepare the removal of
'portal' module.
Since this module only provides access rules and
rights, those ones are moved directly into its
parent module (aka gamification).
Since no module depends on it, we can remove it
without problem.
When you send a quotation, you have a mail template mentionning the
quotation and its price if there is an invoice method, with the quotaion
in attachment.
When you select an invoice method different than 'No Invoice', all the
parts lines except the 'Remove' ones and the fee lines will be invoiced.
When you print a quotation, the price of parts and fees is shown
only if you have an invoice method (you only have the quantity if you
don't invoice)
The invoice is available through a stat button.
The price of removed parts is set to 0.0 by default as it won't be
invoiced.
When unlinking an ir.model, all the ir.model.constraint linked to this
ir.model must be removed to avoid to call unexisting model.
The ir.model.constraint records, are created with module = the module where the related field
has been declared. But when unlinking the ir.model in function _module_data_uninstall, the related
ir.model.constraint to remove were chosen according to the removed modules. So with models
declaring constraints on inherited fields, some problems occured because the model could be removed
and not all the related constraints.
opw:716032
A customer facing display is any monitor that can be connected through
HDMI on the POSBox. When enabling the customer facing display option the
customer will get a realtime overview of their current order, what they
have to pay and the change they should receive.
What is displayed on the customer facing display is fully customizeable
through web_editor, two snippets are provided that will be dynamically
updated (Order Block, Payment Info Block) as the order changes in the
POS.
The POSBox handles the live updates through hw_screen.
The HTML that eventually gets sent to hw_screen contains references to
remote resources. All of these remote resources are available on the
Odoo server, no other external connections have to be made. Resources
that are unavailable for the POSBox (like product images) are base64
encoded and included in the HTML. This is accomplished by using the BASE
HTML tag. This does mean that the customer facing display will *not*
work with a POS client opened through localhost or 127.0.0.1. The POS
has to be opened through an IP address (or URL) the POSBox can reach.
Courtesy of JOV, LPE, GED and MAT
Having more than one supplier invoice with the same reference is sometimes
possible. For instance, in Switzerland, the use of BVR/ESR numbers as a type of
reference permits this. Generally, this number is unique and used only for one
invoice. However, some suppliers do use the same BVR reference for several
invoices (e.g. recurring invoices).
This commit allows to disable this check if required, which is only possible
if it is extracted from 'invoice_validate'.
Closes#15891
Dhaval Panchal