- Add a "Filter by Industry" filter on top of the "Filter by Country" on the main /customers page. It should work similarly to the filter by "Level" in the /partners page of crm_partner_assign, but would filter on the customer's industry (With "All Industries") etc.
- (Cfr www.odoo.com/customers vs www.odoo.com/partners for live examples)
- The search input field on the main /customer page should search on the Industry field as well
- Add the "Industry" info to the /customers index, e.g. like a badge: http://i.imgur.com/Nzjeck9.png
- Add the "Industry" info to the website_customer.details template, e.g. like a badge or in the address block on the left
purpose
=======
We need to store and produce reports about customer activity sectors to improve references mechanism.
Specification
=============
- add a new model res.partner.industry "Sector of Activity"
- fields:
- name (translatable)
- full_name (translatable)
- active
- add minimalist form and list views (à la Contact Tags)
- menu: Sales/Settings/Contacts/Contact Industries (Technical Settings only)
- ACL: R for group_user, CRUD for group_system
- add a default XML data file to preload res.partner.industry with the ISIC 2008 aka NACE rev.2 level 1: https://docs.google.com/a/odoo.com/spreadsheets/d/1IrGbHIaaDDkBAS2uGABeNRPndtYbyVBVoYYpQNXnhnY/edit?usp=sharing
- Note: we leave it as an option for end-users to import their own industries, because there are many competing standards: ISIC, NACE, NAICS, OKVED, etc.
- Each standard also has different hierarchical levels, and we only use the top level one by default.
- add a m2o industry_id ("Sector of Activity") on res.partner towards res.partner.industry
- add industry_id in partner form view, in Sales & Purchase > Misc, only visible when contact type is Company
- No quick create for this field
The mrp.unbuild model creates a name based on a sequence if no name is
given in the value dictionary. This was fine before the new views,
because the field name (in the form view) was marked readonly, so the
value 'New' was not actually sent to the server.
However, this was changed with the new views: readonly fields are always
sent on create/write operations, if they have been modified. This is a
problem for the mrp.unbuild model, because this means that each new
record as effectively the same name: 'New'.
So, we simply always use the sequence-based names in the create
operation, when the name is 'New', instead of the value given as parameter.
The prettifying of html when editing sources (user need to be in debug
mode to see the button) was removing too much spaces in some instances.
For example if someone got in a case such as:
<span>hello<b> cruel </b>world!</span>
The spaces between text and tag would be removed (this would work fine
with the space outside of the tag).
This code add a special case so this doesn't happen anymore.
opw-743565
closes#17142
Before this commit data-precision='0' was ignored by qweb rendering.
Now we force the data-precision to be set even if 0. (cast in str)
And add a temporary fallback JS side to catch this case while people don't
update the qweb template.
This commit closes#17050 and closes#17046
Before this commit, the o_field_invalid class was not removed once an
invalid field becomes valid, until the user saves the form view (which
will rerender the full view anyway)
It is not really easy to handle discard operations. We need to handle
the discard in editable lists, and in x2manys. This is not exactly the
same code, but most of this was done by moving the discard method from
the formcontroller to the basic controller.
With this commit, the user can now discard the changes for the current
record by pressing ESC. If the record is new, it will remove it, if
not, it will ask for confirmation before.
The issue that we fix in this commit is the following: open a form view
with a o2m with one required field, and the o2m is editable. When
adding a new line, it is invalid (since the field with required), but
when pressing ENTER, the editable list tries to navigate away, which
will discard the current line (in the unselectRow method), before
completing the move_to_next_line. So, at this point, the list editable
create a new (empty) record, and we are back to square one, but with a
visible flicker and no information on what happened.
To fix this issue, we simply check that the renderer can be saved when
moving to next line. If it is not (the line is invalid), then we simply
abort the move.
Notes:
* this behaviour worked fine in list view, because the canBeSaved check
is made by the saveRecord method in listController
* it looks like the protection should be put into unselectRow, but this is
not true (at least, in the current state): in some cases, calling
unselectRow with invalid state should result in discarding the current row
(in a new line in a o2m, when the record is not dirty, for example), and
the list editable renderer does not know if this is the case or not.
However, if the unselect action comes from a navigation event, then we want
to avoid discarding the current row.
When a many2one (in an editable list) with an onchange was edited, it
could happen that a modal window asking for confirmation of the creation
of a record was opened when it should not. Here is what actually could
happen:
* user focus a many2one
* user type something
* user press ENTER (keydown + keyup)
* user press ENTER again
* the onchange comes back
* modal window is open
Because of the onchange, the _reset method was called after the
_onInputKeyup method. So, the m2o_value was not equal to the
$input.val() and the 'floating' flag was set to true (after the first ENTER).
The second ENTER caused a unselectRow in the editable list, so the input
was focusouted, and the modal is set. This is basically caused by the
asynchronous behaviour of the onchange.
We simply fix the problem by setting the floating flag back to false in
the keydown method.
When a many2one (in an editable list) with an onchange was edited, it
could happen that a modal window asking for confirmation of the creation
of a record was opened when it should not. Here is what actually could
happen:
* user focus a many2one
* user type something
* user press ENTER (keydown + keyup)
* the onchange comes back
* user press ENTER again
* modal window is open
Because of the onchange, the _reset method was called after the
_onInputKeyup method. So, the m2o_value was not equal to the $input.val() and
the 'floating' flag was set to true, which means that the _onInputFocusout
method (called indirectly by the listeditablerenderer when unselecting the row)
was forced to open a confirm dialog.
We simply fix the problem by setting the floating flag back to false in the
reset method.
Before this commit, when the user write some text in a many2one, then
press ENTER, the key event will trigger a navigation move, which will
validate the field, and move the focus to the next line. The same issue
happens when pressing TAB.
With this commit, we simply stop the propagation, and preventdefault the
event that cause the selection.
Before this commit, when editing a many2one (with an onchange) by
clicking on the small form button on the right, then changing something,
then saving the modal dialog, no onchange was triggered, because,
technically, the value of the many2one was not changed, only the values
from the record pointed by the many2one were.
The same remarks applies to many2manys.
To see this issue in odoo, you can open a product (technically, a
product.template) from the 'Catalog' menu in sales, then edit it, then
click on the small form view icon next to Internal Category. This is a
many2one (categ_id) with an onchange. In the form view dialog, change
something, for example costing method, then save. The res_id of the
internal category was not changed, but an onchange should still be
triggered.
With the settings:
- Anglo saxon accounting
- real price on product, perpetual accounting,
- multicurrency
- a product with a very small uom (like gram or kilograms and you want to sell many of them, like 500kg)
Flow: purchasing something in another currency
Before this commit, the rounding of the unit price took place right at the conversion level
which led the rounding errors to be amplified by the quantities when the total price was computed
After this commit, the conversion is done on the unit price but is not rounded yet
Only the prices are rounded, as late as possible
OPW 742293
Closes#17015
The cash_control flag on a session will be true if at least one payment method
is cash and the config has cache control.
However, the prevents to enable the flag on the config if one session in the
past had no cash method. As the field is not stored, it will be recomputed if
displayed (or prefetched) and raise an error, on a past session.
If the session is already closed, never raise an error
opw-744314
When a SelectCreateDialog was opened with a given domain, this
domain was completely lost if the user wrote a new domain (or
groupby) in the searchview, whereas they should be concatenated.
Suppose that there is a one2many list in a form view containing
a field F, displayed with no widget, and that F is also displayed
in the one2many form view (opened when clicking on a record of the
list), but that in this form view, F is displayed with a widget
requiring specialData (additional data to fetch alongside the
record), e.g. widget="domain".
Before this rev., it crashed when this happened because those
specialData weren't loaded when opening the related record.
Credit goes to @pga-odoo for reporting the bug and reproducing it
in a test.
DebounceFields debounce the function that notify field changes to
their environment (using _.debounce). It may happen that this
function is called once the field widget is destroyed (e.g.
type something in a char field and quickly click on Save, the
function is called directly by _commitChanges, but the debounced
call is still pending). It may be a problem if the subsequent
code does something like this.getSession().some_key, as if the
widget is destroyed, it has no parent that can provide it the
session, and thus it crashes.
Also rename attribute _debouncedStarted into _isDirty as it makes
much more sense.
Summernote doesn't call the onChange callback when changes are
done in the code mode, so the html field isn't aware of those
changes. It means that if the user does some changes in code mode
and then save directly (without coming back to normal mode), those
changes are lost.
This rev. ensures to save every changes by manually come back to
the normal mode before saving, as this will correctly trigger the
changes. Actually, it simply restores some code of the previous
implementation (before new views) of this widget.
Purpose
=======
Improve label in full mail composer.
Specification
=============
In full mail composer if it's log than send button string should be "Log".
Passing multiple ids wasn't correctly handled as the argument `record_id`
was wrapped in a list of list, which is not hashable.
The wrapping is now handled by the caller.
Before this commit, the renderer interpreted the special tag, but ignored
modifiers and attributes.
Most nodes are rendered by the `_renderGenericElement` method, so this behaviour
is automatic. However, special tags need to do it explicitely.
The previous trigger would recompute all sessions of a config when modifying
the cash_control flag on the config.
It was not possible to enable cash_control if a previous session wasn't in
cash control mode.
Recompute only when changing the config.
Before this commit, when creating a new record, we only looked at the
main fields to determine if a call to onchange was needed. This was not
enough, since sub fields (fields in a one2many for example) can have an
onchange.
This was an issue only for new records with onchanges in sub fields, but
no onchange on main fields. For example, the merge contact wizard.
To solve this issue, we had to propagate the current view type from the
field to the basic model, because otherwise, the main viewtype was used
to compute the onchangeSpec, and that is not always correct.
`_cart_find_product_line` can return more than 1 order line . Since it
might be necessary in `website_sale_options`, just prevent the crash.
opw-743805
The maintenance.request "active" field was renamed to "archive" for some
strange reason by commit 9a20c6556f.
The value was also inverted.
Unfortunately, "active" was not replaced in a search filter.
opw-744168
Introduced at 0570033ae7. Normally not a
huge issue (you just end up with a '>' character). But unfortunately
in this case it crashes the hw_escpos driver since it tries to parse
the content of that element as a float.
opw-744222
7836a83b3b was implemented for 9.0 and
uses the pos property. It was forward-ported to saas-11 and up. This
particular property was removed in saas-11 at
467ba386f4 because it was unused.
opw-744222
- Create a contact
- Create a lead
- Convert lead to opportunity w/ link to existing customer option
Salesperson on the lead to opportunity merge overrides the salesperson
in the contact record.
Link with existing customer should not override salesperson on contact
record. The two fields should be independent of each other unless you
are creating a new contact.
opw-659028
opw-740526
Localizations depend on the module "base_vat". It is therefore
impossible to remove base_vat without the localization. This causes
issues for users who simply want to deactivate the VAT check.
opw-743260
When making a quick create for a crm.lead record, the field user_id is set
with its default value (introduced by aa44700dcc)
But the date_open('Assigned') was not set.
When creating a challenge with goal="New opportunities", the new opportinities
are counted with date_open. But when creating an opportunity with the quick create,
it was not counted as date_open was empty.
opw:742751
When creating orders from the interface, all the orders of the current session
are in the cache and slow compute methods are recomputed.
Clear the cache before evaluating to execute _compute_amount_all on the current
order only.
The cache mechanism has changed in v10 and no longer contrains all orders.
opw-741442
Let's consider a stockable product P with a product category PC with costing method = real price,
valuation = perpetual, stock valuation account = SVA and price diff account = PDA.
The cost defined for P in product.template is equal to 1$.
Steps
-Create a PO for P with a price unit = 5$
-Confirm PO and generate the invoice
-Update the qty for P in the invoice and validate it(price unit is still 5$)
Bug:
In the general ledger: a move with a debit of 1$ is created for SVA and a debit of 4$
is created for PDA which is wrong. The expected result is: just a move of 5$ created
for SVA and nothing for PDA because the difference between the purchase price and the
invoiced price is 0.
This commit fixes this problem.
NB: in real price and average price, the considered cost must be the purchase price
and not the cost defined in the product template.
opw:740879
Purpose
=======
Don't display sales app icon in Odoo homepage when installing ecommerce (only website should be visible)
it's confusing to have sales icon -> where do I manage my sales? In sales or in website? -> in website
Specfication
============
We need one new modules to add Sales menus to the homepage. Currently they come with "sale". So when installing "website_sale", we get them (because sale and account are dependencies of website_sale). We don't want that anymore. Along with that you need to replace modules in Apps menu:
sales menu items must be in the new sale_management module, no longer in sale
- create new app "sale_management"
- Currently 3 app icons when installing ecommerce (Sales, Invoicing, Website) -> too many icons, where to start? -> GOAL: Only 2 icons > Website, Invoicing
- new module to display Sales Icon (like account_accountant): "sale_management"
- move menu items to sale_management
- sale, sale_management: move app description, rewrite the manifest file
- sale, sale_management: move tour from sale > sale_management
- Changes in some dependency module "sale" > "sale_management" modules: event_sale, mrp_repair, pos_sale, report_intrastat, sale_crm, sale_expense, sale_stock, sale_timesheet, website_quote
Menu items to move 'sale' --> 'sale_management'
===============================================
Sales
Quotations
Sales Orders
Invoicing
Orders to invoice
Orders to Upsell
Catalog
Products
Product Variants
Pricelists
Reporting
sales
Configuration
Settings
Products -Attributes, Attribute Values, Internal Categories
Yannick Tivisse
