[FIX] mrp.bom: wrong check for bom_find.
If the user defined a bom line type phantom to a product without bom the check is wrong to display the error message.
This fix aimed saas-5, not master.
original Commit message:
display accessory field in form view and display the good accessory product inside ecommerce
This is related to previous rev 86055fb8cd
This many2many field should actually have product.template as relation
But, in a stable release, we cannot alter the database
Therefore, when displaying accessory products in the card, it display the product_tmpl_id of the product.product, not itself
This relation should be changed in trunk
+ Actually displaying this field in the backend
Subclass detection didn't include the class itself if all it's subclasses
were invalid. As we create a new regrouping subclass, that was always the
case after a registry reloading, causing subclassed controllers to not be
taken in account.
[IMP] routing_map: clean code a little bit
[FIX] website*: unfuck buggy controllers
[IMP] website*: display GoogleMap in a human-usable interface
[IMP] website_google_map: large module cleaning
- There is now only one controller, data is sent once for all!
- Map is now fully resizable in its hosting template
- HTML/CSS cleaning
- JavaScript is now human-readable ;-)
- fixed subscription, was always subscribing to the last created list;
- slightly improved the snippet display, now displaying a 'thanks' when subscribed instead of just making everything disabled;
- removed unnecessary JS line
[FIX] product: add module 'report' module in its dependencies
The product pricelist report model inherit from report.abstract_report but report was not present in dependencies.
[FIX] product
Context in _set_standard_price and many2one in product.packaging;
Set required at false for product template field when creating a product product;
Remove wrong field on product.template. TODO: move packaging field form product.product to product.template
[FIX] mass_mailing: fixes
- backport (+ cleaning) of eb22d202e4 (saas-5): mail_thread: routing: instead of exclusive routing heuristics, use each case as a fallback of the previous.
- better fix for dd36a0e509 (saas-5): mail_thread: routing: fixed replies always choosen even when replying to emails with a specified reply_to (using ref_match in the algorithm)
- backport of d6a2ae642b (saas-5): avoid evaluating a False / None domain
- fixed keeping the original message for routing, only when choosing to reply in the original thread (notification=True)
- mail_thread: routing: fixed replies always chosen even when replying to emails with a specified reply_to (using ref_match in the algorithm)