Better tooltips for settings options:
- Pricing Strategy: remove tooltip
- Sales Price:
- Specific prices per customer segment, currency, etc.: new pricing table available in product detail form (Sales tab).
- Advanced pricing based on formulas (discounts, margins, rounding): apply price rules from a new *Pricelists* menu in Configuration.
- Optional products: Installs *e-Commerce Optional Products*
Better tooltips in product page:
- Website Categories: Categories can be published on the Shop page (online catalog grid) to help customers find all the items within a category. To publish them, go to the Shop page, hit Customize and turn *Product Categories* on. A product can belong to several categories.
- Suggested Products
- Relabel the field on product detail form, web page + web customize menu: should be Alternative Products
- new tooltip: Propose more expensive alternatives to your customers (upsell strategy). Those products show up on the product page.
- Accessory Products: Accessories show up when the customer reviews the cart before paying (cross-sell strategy, e.g. for computers: mouse, keyboard, etc.). An algorithm figures out a list of accessories based on all the products added to cart.
- Optional Products: Optional Products are suggested whenever the customer hits *Add to Cart* (cross-sell strategy, e.g. for computers: warranty, software, etc.).
- Availability: Adds an availability status on the web product page.
Steps to Reproduce:
- Company set in USD
- Customer Invoices journal set in USD
- Related account set in USD
- Create an invoice, validate
It raises an error: "The selected account of your Journal Entry forces to provide a secondary currency. You should remove the secondary currency on the account."
The error should be raised if the currencies are different. It should be transparent to the user if the currencies are the same. It should raise an error when:
- The journal currency' and Currency of Accounts Selected on Journal are different
- The journal currency is blank (by default company currency) and the account currency is other than company currency
+ Some wording improvements
A user portal cannot have the read access right on the res partner, except his commercial_partner_id (his partner or the root partner if he got a parent company). That would a big security flaw.
In the header we use the contact widget to print the company information. This widget uses sudo to get all the required fields to display.
But in the footer, we still access some fields like company.fax which is not allowed.
As the contact widget uses sudo to display the company information in the header, we did the same here for the footer.
The portal user should have acces on the procurement orders because this model is present on some models like sale orders to avoid issues on printed reports.
Currently, when an user portal prints the Delivery report (report_delivery_document) from 'My Account/Sale Orders', he got an ACL Access Denied to print the sale order reference because he cannot read the procurement orders on the sale order.
PURPOSE
=======
For each and every Hr application there should be one user category (One app = one category).
SPECIFICATION
=============
HR remains as it is : Employee, Officer, Manager
Each Application should have 2 access rights: User and Manager. Example for Recruitment:
- The user has access to the recruitment process
- The manager has access to the job position configuration
Each Application should grant the employee user access right (Namely the 'HR Officer')
Now the porperty product pricelist is computed automatically.
Based on the res_country of the res_partner, and the pricelist available
for this country.
It is always possible to force another value (property) that the computed.
Now that property is computed automatically.
In some case, the compute will take the first on available.
So, the order (sequence) allow to specify the priority.
Test from point of sale are base on currency $,
So we force for the test to use a pricelist in dollard (My company, Chicago)
Now, the user can choose on the pricelist if the price should be displayed as a
discount or not (price striked red).
cart_update and confirm_order recompute unit price by default.
So we need for website_event_sale to be able to ask to don't recompute the price.
Else the price of product will be used instead of the price of ticket.
In 8.0 private fields have been recently set as visible only to employees
at commit b226510840.
However between v9 and v10 two new payment acquirers have been implemented
payumoney and stripe. Those addons now have their credential set as private.
Methods using the acquirers have been sudoed accordingly to avoid access
issues when rendering the buttons. Other payment modules will be updated when
the forward port from 8 to 9 and pre-10-master will be done.
If your create an order in backend and you make payements, they remain opened while the POS session isn't closed, which may seens counter-intuitive. The payment in taken into account afterward and the reconciliation is made with the invoice (if applicable)
We shouldn't let people create POS orders from backend. And while we're at it, we should do the same with sessions. They're opened and closed from the dashboard.
There already is a redirect implementation in the chat_manager
which closely matches the on_redirect implementation in chatter.js,
however the former has the advantage of calling get_formview_id
to ensure that the view is correct.
This fixes a faulty behaviour when some models are referenced from
chatter message using data attribute data-oe-model and data-oe-id.
For example, linking invoices in the chatter would always open them
with the 'vendor invoice' view; from this revision on the correct
view will be used (assuming get_formview_id is implemented on the
model).
The default behaviour of the chat_manager when a user clicks on a
partner record is to open a channel if the partner has a user then
return a callback passed as a parameter (usually to open the channel
as a popup or in the discuss app). To keep the old behaviour
of the chatter followers list widget (i.e. open the partner form
when clicking on a follower), a small change has to be made on the
redirect implementation: when no callback is provided, do not create
the channel (instead a returning an empty callback).
The default order on `sequence` was not specific enough,
causing semi-random selection of picking type and warehouse
when several types exist with the same sequence.
The problem was made more likely by the fact that
warehouses create their own picking types.
The algorithm to determine the sequences for the
new types was not handling properly the case of
a NULL sequence.
The patch fixes both issues: the selection of the
default picking type (e.g. for purchase orders),
and the algorithm for choosing the sequence for
new picking types.
* Replace mail theme/template system with a cleaner one which only
allows to change a class on the main container of the mail
* Improve snippets
* Improve snippet options
* Improve web_editor UI
* ...
* Remove mass mailing template switching system (lemon, airmail, ...)
and replace it with a theme selector which only toggle a different
class on the body.
* Lint JS files.
* Change the way the editor is overridden by mass_mailing in a more
odoo way (put the JS in assets and check on runtime if it must be
applied.
+ fix editor style
+ remove useless code
+ remove odoo template
Instead of showing the columns delivered/invoiced qties on SOs
by setting a special key in the view's context, let's do the opposite
and hide them for a sepcial key instead.
The rationale behind this decision is that when a user wants to see
a SO from another place in the system, it is often a SO and not a quote
(i.e. accessing from an invoice's chatter message, from a subscription,
etc.). The default should then be to show these fields unless otherwise
specified in the context (and not the opposite).
This commit is a port of a17c09af to master
The email templates may contain non-html content (mako) which should not be
sanitized.
Changing this attribute to sanitize_attributes made the translations to be split
when translated.
Double tap
* fix wrong group xml_ids probably introduced when rebasing the branch
removing workflow after xml-id-pocalypse
* fix wrong group used for buttons, should be for Billing users
There is a traceback when we are trying to install module from the list
view and clicking on the button 'Module Immediate Install'.
This traceback appears because of a server action that has not been migrated
during the rev https://github.com/odoo/odoo/commit/d465346f1
To fix this, we've converted the server action in new API.
When we create a timesheet activity, it create an analytic line that allows to re-invoice the costs from the employee. If the account_id is not set on the analytic account line, the employee cost is not passed correctly on the Analytic Entries, which is not the behavior we should expect.
This commit simply adds a account_id on the employee and this account is returned with the cost and the uom by the method `_get_timesheet_cost`