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.
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.
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)
=======
Purpose
=======
The company form should be heavily simplified. It's complex to have some settings on the company form, and others on the Settings menu of the related app. It would be much easier to have all settings in Settings menu (res.config) and nothing on the company, even if some of the Settings are multi company. (Stored on the company but set from the Settings menu).
Historically, developers had to use the `eval` attribute to set
a False value for boolean fields in XML data files:
<field name="active" eval="False"/>
This is a source of errors for beginners, who tend to provide
a string value directly, as for char/text fields.
Unfortunately string values always evaluated to `True` booleans:
<field name="active">False</field> <!-- active == true! -->
This patch adds detection of some well-known falsy strings
(case-insensitive): `0`, `false`, `off`, as similarly supported
for the `noupdate` and `forcecreate` attributes of XML data records.
Closes#13152
* The debug manager contains a feature to launch tours, adapt it
to new web_tour.tour system
* The website help menu allowed to relaunch tutorial tour in debug
mode. This feature is not adapted to new tour system and was useless
in the first place (debug mode in frontend is barely used anyway).
-> remove the website help menu and the feature
When the statusbar is clicked, a `debounce` function prevents a
doucle-click, and therefore making several `write` calls. In debug
mode, the click doesn't work anymore.
For some mysterious reason, the event is propagated to the parent. The
`currentTarget` is not the `li` element, but the parent `ul`. By
setting the `immediate` argument to `true` (execute the first function
instead of the last), this solves the issue.
Since res.users is an inherits of res.partner, the onchange that
should be triggered by tz to update tz_offset is not triggered.
Considering tz_offset is never used on res_partner and is only
used by the timezone_mistmatch widget which compares the offset
with the one of the browser timezone, which only makes sense if
you are a user, we could have completely moved this field on
res.users. That being said, it feels strange to have a tz field
defined on partner but having to be a user to compute the actual
timezon offset, which doesn't need any additional information.
For this reason, we chose to duplicate it until either we decide
to truly move it in the next version, or the orm is fixed to
correctly trigger the onchanges of the inherits models.
This patch could be applied in 9.0 if needed, but considering
nobody ever complained about this issue and the "workaround"
nature of this fix, we decided to apply it in master only.
stage_id is comptued and based on stage_ids
The default value should be put on stage_ids, not stage_id, it has the same
effect but avoids an unecessary chain update.
The account.move has already self.date for the date field (cf the method
`_prepare_reconciliation_move`). As the field date on the account.move.line is
a related, it makes useless updates to write it here.
Same issue for journal_id field
ref is a related set on the account.move. Writting on the line set the same
reference for all the lines and the parent move (the one of the last line).
Instead put it on the move if there is only one reference or do not put a wrong
one if we can't determine one.
Avoid setting a value for a related field as it will trigger onchange update.
This code was relevant when the date was different on the move and the line but
is no longer needed.
Remove all the `if vals.get(mandatory_field)` to simplify this method and remove
dead code or condition always true.
The field journal_id and date are both required on account.move and are stored
related on account.move.line.
Setting the required on the account.move.line allows to make it required in the
views or for the ORM but in practice it will be same as it's required on the
parent.
Making it required is a performance killer as it forces to specify a value for
the create which will retrigger an update on the parent move.
This means that adding a line with a date value on an account.move with already
10 lines will trigger 11 updates (date of the new line -> date of the move ->
date on the 10 existing lines), even if the value has not changed.
Since commit 2ab68047, the Paypal link can be sent in an invoice as it
was the case before. However, in order to be able to save the Paypal
account in the accounting settings, the Paypal account must be
website-published. If the module `website_payments` is not installed,
this is not possible.
We remove this condition, since it should be possible tu use the Paypal
payment method without installing the whole website.
opw-686216
Currently some customers receive the automatic notification 'Quotation
viewed by customer'. This should not be the case as this notifciation
is purely internal and should only be sent to the quote responsible.
Notification is now a note with the responsible being directly in the
recipients.
Commit 933949085d added the odoo variable
definition in the iframe template so the condition which checked if
odoo.define is available had to be adapted.
This reverts commit a57b10dbd5. This has to be fixed in 8.0, and moreover it uses fields defined in sale only so the fix must be done in stock_dropshipping module
The nocontent message was never there when the kanban had no content
in grouped mode and the create button was muted even if no column can
be added. Also it was wrongly displayed in ungrouped mode.
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)
Workflows are removed and replaced by python code directly embeded in model
files. There are several reasons to do this
* most of workflows are simple state machines. They simple go from state to
state under simple conditions. Short circuits exist allowing to bypass
part of the flow, like cancelling a record. However it is easier to
understand a flow composed of several simple methods than having to
understand the workflow in a separate xml file
* workflows are hard to debug and modify. Each modification require a small
migration. Moreover ensuring records are not blocked or that there does
not exist unreachable states is hard to do.
* having all business code in models helps understanding the business code.
* most of our flows are quite simple and does not require a complex machinery
to reflect it
Workflow engine itself is kept. Lot of people use it and it can be very
useful in some cases, notably in modeling more complex flows. Removing it
is therefore not planned in this task.
Commit 744cd64b53 re-added the removed
col system in the title snippet but did not respect the odoo structure
which is section > .container [> .row > .col-*] and put the container
class directly on the section. With this method, when changing the
background of the snippet, only the container part is filled
with background.
* On firefox, you had to click twice on a link to be able to start
typing text
* When selecting text which contained a <br/>, you were not able to
replacing it correctly (you had to click again before starting typing)
* When replacing a whole paragraph content which was below a title,
the text was not replaced and you had to click again and the title
transformed into a paragraph.
* ...
Christophe Simonis