If the user has multicompany rights and more than one allowed
companies, the full company name is displayed in the topbar. When you
click on it, there is a dropdown with the name of the other companies.
Clicking on another company name makes you switch on it and reload the page
Modify the implementation of inheritance (with `_inherit`) between models, in
such a way that extensions to a given model are visible to all its children
models.
Inheriting model A to extend it adds the current class to A's model class.
This works like before, except we do not recreate the model class.
Inheriting from A in B adds A's model class as a parent of B's model class, so
that all modifications in A's model class are visible in B's model class.
Moreover, the `BaseModel` class has been introduced as an abstract model
`base`, and is implicitly inherited by all other models. That model may be
extended to add a feature on all models, or override a method on all models.
Not committing the current transaction may block the deinstallation of a
module. Specifically, if a module adds a field on model `ir.module.module`,
its deinstallation will block when trying to remove the column, because the
wizard's pending transaction made a query on the table `ir_module_module`.
In particular, reset `compute`, `inverse`, `search` and `related`. This is
necessary because all models implicitly inherits from model 'base', and the
latter defines `display_name` as a computed field.
Those cases can now appear, since a model inheriting (with `_inherit`) from
another model can observe those extra fields from its parent model's class.
With this subclassing, the MRO of the model class will always traverse `Model`
before `AbstractModel`. This guarantees that inheriting from an abstract model
does not make the current model abstract.
When a model B inherits from model A, any extension of model A should be
visible in model B. We achieve this by:
- making B inherit from the class of A in the registry;
- making model extensions modify the model's base classes.
- Separate group_stock_multiple_locations into 2 groups:
o group_stock_multi_locations
o group_stock_multi_warehouses
- Add a selection fields to manage the 3 levels of warehouses management complexity:
o Manage 1 WH with 1 location
o Manage 1 WH with multi locations
o Manage multi WHs with multi locations
- Display the menuitems and fields accordingly
- On a company creation : Create a related Warehouse
- stock.location : Add a helper on the parent location
- stock.warehouse : Add a helper on the company_id field
A similar protip has been added in the enterprise 'account_reports' module.
We took this opportunity to rename the class protip into o_protip and to apply
this kind of style with standard attributes and classes + to correct typos
Lead times are too advanced for most of our online users. Most of the companies just
buy and sell and don't manage scheduling. As an example, when they do MTO, they
purchase the same day they sold.
The problem with current lead time is that users don't understand the dates produced
on delivery orders and receptions. They even have receptions in the past, and they
don't understand why. (customer lead time default to 7 and vendor lead time to 1,
as well as security days, ...)
- Restructure the menus this way:
Sales Flow
Pipeline
Proposal
Deployment
Incoming emails
Customers
Products
Prices
Reporting
Customizations
- Add a short intro about leads in Incoming emails (why using leads?
first contact, contact forms) -> in incoming email menu
"There are several ways for your company to generate leads with Odoo CRM.
One of them is using your company's generic email address as a trigger
to create a new lead in the system. In Odoo, each one of your sales teams
is linked to its own email address from which prospects can reach them.
For example, if the personal email address of your Direct team is
direct@mycompany.example.com, every email sent when a new prospect
contacts you will automatically create a new opportunity into the sales team.
That's the easiest way to integrate Odoo with third party apps.
Only call `product_id_change_margin` method if exists. This method is
defined in `sale_margin` module, but as there is no dependency between
modules (nor a bridge module), the call have to be done here.
The condition self.uom_id != self.product_id.uom_id could actually
never be met, since a few lines before you could read
self.uom_id = product.product_tmpl_id.uom_id. From now on, simply
check if the uom_id on the cached record is different from the one
on the product and check the price using the pricelist (_compute_price
does not take pricelists into account) with the wonderfully explicit
with_context call.
Code introducted by commit f39e535 was ignoring the value.
Now, we change the logic to always have True as value regardless the operator.
!= False become = True ...
Use case: I can create a Channel on a chatter, for example on a task
If I choose create and edit, there's another window coming where I
can set up the Channel. In this situation I can't add any members.
But then as the channel is empty and I (as the creator) am not by default
in that channel, I can't find it in my Channels in Discuss...
Commit c04103f re-renders the thread every minute to update messages' date.
As a consequence, the expanded messages are lost (they are shortened again).
This rev. makes sure to keep those messages expanded.
Yannick Tivisse