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.
* ...
When the statusbar is clicked, a `debounce` function prevents a
doucle-click, and therefore making several `write` calls. On some status
bars, clicking doesn't work anymore.
The reason is because, in some mysterious cases, 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.
Note that to copy the workflow, just after creating the state is updated
to draft. The 'New' state is not used anymore in the flow. It could
probably be cleaned. However in this task we only remove the workflows
without changing their behavior to avoid unwanted side effects.
This report is too advanced and/or complex to be a single menuitem. Furthermore the model was a mess and a horn of plenty for bugs.
The class ProjectTaskHistoryCumulative inherits from the class ProjectTaskHistory, and create a view based on the same model.The orginal class defines a compute field 'end_date' which calls a compute method '_compute_end_date' that will either make a simple assignment or a SQL request if the columns is always opened or folded.
As ProjectTaskHistoryCumulative is declare with '_auto=False' the compute method will try to write on this table, which is obviously wrong because we are trying to write on a view.
This leads to erors when trying to edit a project stage like:
OperationalError: cannot update view "project_task_history_cumulative"
DETAIL: Views that do not select from a single table or view are not automatically updatable.
HINT: To enable updating the view, provide an INSTEAD OF UPDATE trigger or an unconditional ON UPDATE DO INSTEAD rule.
or when trying to delete a column which already contains some tasks.
So we removed this these models and view and replaced them by a simple favorite filter in the Tasks Reports
When removing the "Save as Attachment Prefix" field
of the Invoice report (`account.report_invoice`),
it was no longer possible to reset the invoice to draft
opw-687130
When the purchase model is installed, there are two checkbox with
label 'Can be Purchased'. This error is due the rev https://github.com/odoo/odoo/commit/e945b86d5a61e53a9104ab6cc4ed4a1c060587e4
where we moved purchase related fields from module product to an
inherited view in purchase module.
To fix this, we removed the 'purchase_ok' field that was left in
the product_template view.
Barcode, default_code (Internal Reference), standard_price,
volume, weight fields are not saved when we create a new product.
This is due to the fact that these fields need the product_variant_ids
field to be set, in order to compute their values.
Due to migration in rev https://github.com/odoo-dev/odoo/commit/1aa5bc0fdfa402ac7cccbc3a7203ec5050f6339b
This commit improves the tokenization process, allowing users
to set the acquirer to save payment data never, always or letting
the customer decide (only implemented in ecommerce for now).
Support for tokenization is improved for Ogone and Authorize.net
This commits also factorizes advanced payment features support
(authorization, tokenization, fees computation) in a generic method
overriden by every provider to specifiy which features are supported.
This process can be used in views to hide/show fields depending on
feature support or in constraint checks.
This commit add s2s communication to the Authorize.net payment
provider, allowing the user to:
- Create a payment token
- Charge a payment token
- Authorize/capture transactions
Since the creates overrides needs some information that do not end up
in the final record, let's avoid warning by removing all non-model
fields from the call to super.
This allows using a modern e-commerce flow where amounts are first
authorized at checkout then captured when the picking is in fact
shipped instead of immediately capturing the amount.
To access this flow, a new selection value is available on the payment
acquirer: "Authorize the amount and confirm the SO on acquirer
confirmation". If this value is selected, s2s/form transactions should
only require authorization to the acquirer; the user can then
capture/void the payment manually from the Odoo backend transaction
form view by simply using buttons.
Since 85bcd6fdd8, the field `paypal_account`
has been removed. The field `paypal_url` cannot be computed correctly
anymore.
This reverts commit 2ab68047c1.
As you open the lots in a raw material move in a production order,
you should not see the temporary stock move lots from the work order.
Also the quantity_done should not take into account those. They will
when they press 'Done' on the workorder.
When posting inventory, the temporary stock move lots on the workorder,
should be transferred to the split move.
For splitting and unreserving, some optimizations are done.
Since 85bcd6fdd8, the field `paypal_account`
has been removed. The field `paypal_url` cannot be computed correctly
anymore. Convert it to a dummy field.
Fabrice Henrion