Another reason why it’s better to change ‘not archived’ into ‘active’ is
because ‘active’ is the functional name of this field in the filter list in list view.
For the rest, it’s just a better en_US way of saying it.
* The compiled templates are cached per user, lang, inherit context values
* ir.ui.fields: attributes method return an dict, and record_to_html return only the content value of the field
* all rendered text use build_text and all attributes use build_attribute
* t-esc-options is removed and replace by format_value method
* AssetsBundle receive the list files and remains
Template arch can contrains "groups" attributes on the html tag but can't have group_id setted. (to allow a cache per template and lang instead of a cache per template, user and lang)
Allow access if the user has at least one group, and has no one !group
E.g.: groups="a,!b,c,d,!e"
(a, c, b) prevent access
(c) allow access
So the negative groups have precedence.
Search terms inside an OR branch in a domain
cannot currently use relationships that are
not required. The root cause is the INNER JOIN
used to implement it.
This allows the user to continue using the attachment feature, without making it public by
default, which was the case in the previous implementation. If you wanted to use the
product digital attachments, you were foresaking the standard attachment feature since
everything you would attach to the product would then be public and downloadable.
The "digital" product type was also removed, because you could very well want to provide
downloads for a stockable product, like an online manual or a warranty document, or
provide downloads for a service, especially considering digital products are considered
service in european laws.
The product template and variants stat buttons have also been changed:
- The template stat button now only displays the files associated at the template level,
instead of showing all the files available accross all variants.
- The variant stat button now displays the files associated with it but also with the
corresponding template, instead of showing only the files associated with the variant.
These new stat buttons are closer to what the customer will see in practice, since the
variant level stat button will show the set of files that the customer will be able to
download when he has bought that product variant. Previously, the template showed a set
of files that was never presented to any customer (since it contained the files from all
the variants at once), and the variant was showing less files, since it was ignoring the
ones from the template.
The unit price of the quote template lines is never be used anywhere
It is logical that pricelists determine the price of products and this
field is quite informative.
Purpose:
The settings planner (implementation guide) is confusing when in multi-company:
- The accounting planner shows information about the current company; which is OK
- But the planner is not specific to that company: it is the same for all companies which is wrong.
Frontend:
- When product has lot/serial tracking open popup for accept lot/serial
number when it selected.
- Add icon in order line to show related lot/serial number and it
indicate status of product lot
- User can add or remove product by lot from current lot dialog box
- Order line quantity don't match with lot line quantity show warning
message
Back End:
- Added model `pos.pack.operation.lot` to manage product lot related
with pos order
- Added state button in pos session form view to show pickings which are
not in 'Done' stage
In master , some places the string "Lot" is used and at some places
"Serial Numbers" is used , which is very confusing for the user.
Make a common string "Lots / Serial Numbers" everywhere for the uniformity.
Purpose:
There are too many apps when someone starts to use odoo.
The user installs an app and see at least 6 menus -> too much !
Specification:
In mail module move contacts menu into new module 'contacts' to avoid this
useless app for new users but that can be useful afterward
Purpose:
Having the res_group defined in base and sales_team auto installed
with mail doens't make sense.
- Move the empty res_config class and the related view from
base_setup to sales_team (base_setup only contains the 'General Settings'
model and views
- Move the 'sale' related content from product to sale module (Access rights,
menuitems,...)
- Set sales_team at autoinstall False. The module is installed when needed by
crm or sale for example
- Set sales_team as a dependency of voip. (Access rights defined for configuration
purpose)
- Set sales_team ad a dependency of subscription (Access rights issue too)
[FIX] account: move some ir.model.access to sale module
[FIX] payment: Move some ir.rule to website_sale
[FIX] stock: move some ir.model.access rule to sale_stock
[FIX] project: Move some ir.model.access rules to crm_project_issue
[FIX] mrp: Move some ir.model.access rules to sale_mrp
[FIX] calendar: move some ir.model.access rules to crm
Rename xmlids accordingly. Example: 'base.group_sale_manager' becomes
sales_team.group_sale_manager.
[ADD] sales_team: See own documents => See only his sales team
Moved the "User: Own Leads Only", "User: All Leads" and "Manager" groups from sale and crm
into sales_team module. Add the record rules so that user can see only his Own Sales Team
if "See Own Leads" is sales right and can see all sales teams if he is having sales rights
of "See All Leads" or manager.
When doing an internal trasnfer, you can choose any destination
location in the header, but not on the line
This is problematic when doing a pick-pack-ship transfer. For the pick
move, you may want to change the source destination location (maybe another
warehouse why not) but as the transfer is already validated you cannot
modify it on the form. But with the Operation Details (Pencil button) you
can modify the source/destination location. The only problem is that a domain
is forcing the user to choose a source destination that is a child of the source
destination on the transfer, which makes impossible to choose a destination on
another warehouse. This tool is pretty much advanced, so we don't need to be so
restrictive.
The color of the button "create_move" in a depreciation line is
green if the related move is posted, orange if it exists but not posted and
red in the other case.
opw:678905
Foram Shah