Indeed currently it is only visible in edit mode. However we noticed
people did not trigger the edit mode to find fields they do not expect
to find. Making them visible helps understanding projects can be used
notably for tasks and issues.
* Number of emails should not take into account internal notifications
* Remove Channel and Tasks from issue report as those are not really
used anymore
* Remove New filter as it can be done through stage filtering instead
of using a not obvious heuristic based on stage sequence
A new view is dedicated for that kanban view. It is based on the standard
issue kanban view but using the group_create=false attribute to disable
the ability to create new columns.
It is done using a different view because standard issue kanban view
requires this ability. However it is not possible to achieve that goal
using conditional attributes.
RecordSets were not preserving order when combined
with AND/OR set operators. Order was lost as well
through mapped().
This caused various recurring "heisenbugs" during
tests executions on runbot, specifically comming
in the test of stock_landed_costs.
Using OrderedSets instead of basic Sets to resolve
these operation avoids the indetermination.
This required an implementation of __or__ / __and__
for OrderedSet.
- As of v10, manifest files should be named `__manifest__.py`
- For backwards-compatibility, __openerp__.py manifest files
will still be supported for the time being
- Limited refactoring, to add support for the 2 different
naming conventions
- All textual references to __openerp_.py updated in
documentation and examples
Manifest files are literal Python dictionaries, and
aren't supposed to contain expressions that require
a full-fledged eval.
`literal_eval` is therefore sufficient *and* safer.
This parsing method was already used when listing addons
during startup of the Root controller (http.py, load_addons())
in "Website Admin" settings pricelist groups were not updated because they were
not declared in the view. added now.
Also added group to pricelists menu and fix typos.
Several modules defines records with the external ID `base.foo_bar` while it is
created inside this module (typically menus and groups).
While there is no technical reasons to do so but this may introduce issues:
- these records will not be deleted during uninstall
- if a language is loaded before the installation of the module, it won't be
translated
The uninstallation will only remove the records with an external id linked to
this module (these would only be removed when removing base).
Installing a language before the module will drop the translations not linked
to an existing external id (as it can not be resolved).
This commit correct all the external ids tagged as from base or other incorrect
modules.
hr_gamification should be adding hr groups to the security of gamification.
Creating the group base.group_hr_manager in gamification in case hr is not
installed is confusing and redundant with existing manager groups.
Creating a external id in a different module than the one where the record is
declared is a bad practice.
Setting a correct module is both important for a correct uninstallation of the
module (which uses the module to decide which records to remove) and for the
translations (records tagged with 'base' module needs to be declared in the
base.pot file).
one2many, many2many, text and html fields should take all space in a form view
for a better rendering instead of taking only 2 col or not having the label in
front the field.
When a model has no form defined, a default view is generated displaying all
fields of the model.
The one2many and many2many fields were not displayed on the form, probably for
aesthetic or historical (2008) reasons.
The snippet section can have a color or a background. Previous commit
added the functionnality for its innercolumn too... but having a bg
image on top of another one does not make sense, so only keep the
color option for columns.
In the merge partner wizard, there's a button in the footer which
trigger the method `action_close`. This method is decorated by
an api.multi and begins with an ensure_one() and if you click
on close directly after opening the wizard, self.ensure_one
fails.
The thing is, `action_close` only return an ir.action.act_window_close
action and there's a special attribue you can set in the form
view button to make it return an ir.action.act_window_close directly.
If we use this technique, then there's no traceback anymore. So this
is the fix.
OPW: 684742
When using dropship+anglo-saxon+perpetual valuation, there is no journal
move for the delivery to debit outgoing inventory (since the goods don't
transit by an internal stock) but the sale does credit it so there was a
build up in the holding account that has to be moved out manually.
This was also reported in #12687.
The solution implemented is to check if the invoice line is related to
sale order lines having one of its procurement_ids with a purchase_line_id
set. If yes, it means that it is a confirmed dropship and in that case we
don't call to super (we don't create the cost of sale line).
That means that:
* If the procurement is in exception at the customer invoice time, the
behavior will be as it is currently, but it's fine as you don't know how
the procurement will be solved, and it'll be only at the beginning (once
the config is done it shouldn't go in exception anymore). People will have
to manually fix those amounts with a miscellaneous operation.
* users in anglo saxon mode should not use the 'stock interim account
(received)' on supplier invoices for dropshipped goods, but rather use the
COGS directly (sounds to me logical, and that's actually why I wouldn't go
for the solution to create the stock move entries every time even for the
dropshipped goods. That, and the fact that it would pollute the accounting
with useless moves).
This is a forward-port/cherry-pick of 7bdd4de805
OPW: 684742
When using dropship+anglo-saxon+perpetual valuation, there is no journal move for the delivery to debit outgoing inventory (since the goods don't transit by an internal stock) but the sale does credit it so there was a build up in the holding account that has to be moved out manually. This was also reported in #12687.
The solution implemented is to check if the invoice line is related to sale order lines having one of its procurement_ids with a purchase_line_id set. If yes, it means that it is a confirmed dropship and in that case we don't call to super (we don't create the cost of sale line).
That means that:
* If the procurement is in exception at the customer invoice time, the behavior will be as it is currently, but it's fine as you don't know how the procurement will be solved, and it'll be only at the beginning (once the config is done it shouldn't go in exception anymore). People will have to manually fix those amounts with a miscellaneous operation.
* users in anglo saxon mode should not use the 'stock interim account (received)' on supplier invoices for dropshipped goods, but rather use the COGS directly (sounds to me logical, and that's actually why I wouldn't go for the solution to create the stock move entries every time even for the dropshipped goods. That, and the fact that it would pollute the accounting with useless moves)
Thibault Delavallée