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.
Accessing a related field with `related_sudo=True` on a draft record should
effectively traverse the fields as the admin user. Traversing new records in a
different cache requires that all new records on the path are copied across
caches. Make the copy across caches recursive when the first record on the
path is a new record.
Iterator was consuming the first 45k records.
So don't need to specify an offset, because that will ignore the next 45k.
Eg: if step of 5, and range(1,13),
it will only use [1, 2, 3, 4, 5, 11, 12, 13]
* It is sometime useful to be able to set the package type and the package weight during the delivery
* These fields can be edited during the 'put in pack' operation or after, with a button in the view
* As the weight is computed, a new field 'shipping_weight' has been added
* These fields (package type and weight) will be used in the delivery carrier for the shipping
* Packaging types are now handled in a centralized way for all shippers
When writing on a recordset with duplicates, the ORM raises a `MissingError`
because the rowcount gives a difference with the injected ids. The fix simply
eliminates duplicates from ids.
When a record is exported, an external ID, in the form of __export__.<model>_<id>
is created on this record.
When the translations are generated (e.g. "synchronise terms" wizard), the
translations may be duplicated for records that have been exported. If a
translation is submitted before the export (when the record had no external ID
yet), a new empty translation is created as the module differs in the import.
Creating a new translation may be a problem as the new term (equal to the source
term) will be used as the translation value.
Fixes 9480
When overriding a method that calls its super later on, it's important
that arguments is used to correctly pass all arguments to the super.
Consider the following:
// module 1 (not correct)
method: function(a) {
return _super.call(this, a);
}
// module 2 (correct)
method: function(a, b) {
return _super.apply(this, arguments);
}
If the method of module 1 gets called first it will throw away the b
argument when it calls _super. Therefore the b argument will never
arrive in method of module 2.
The margin in a SO line is the difference between the price unit and
the cost price of this SO line. In function "_product_margin" in model
"sale.order.line", the cost price is equal to the purchase_price or
the standard_price of the product. Then the cost price in the SO line
must be set with the same value when creating SO line linked to the delivery.
opw:668090
Add the normalized quantity to the SO line. This field is useful for
delivery carriers, since the package price depends on the weight, which
is always defined as a function fo the product UoM.
opw-667594
The order of a bank statement lines is entirely done on the sequence:
`_order = "statement_id desc, sequence"`
The `create` method of `accounT.bank.statement` is overriden
to handle the sequences of each line.
The `write` method as well, except that the set of the sequences
lines is done after the call to `super`. So, if you add
several new lines to a bank statement, the order of the line
you just added can be different before and after save,
as the sequence of these new lines are not set before
actually writting them on the bank statement.
The widget `handle` serves this sequencing purpose. The
fact it isn't used here is most-likely because
it did not exist at the time this was designed.
Besides, this gives the possibility to the user
to add a new line and re-order it where he wants.
For instance, when manually entering a bank statement,
a user could skip unintentionally a line. If he would
like to add it at the right place, before this revision,
he would have to delete all the lines coming
after the line he skipped. Now, he can add
it at the end, and re-order it where he wants.
What is done in the overriden `create` and `write`
is now useless, but we left it for retro-compatibility
purposes, for databases updating their sources without
updating their views.
opw-667541
Raphael Collet