Issue: An employee submits an expense report and this report is refused by the HR or the accountant (Wrong amount, one line will not be paid,...). Currently the expense fields are readonly except in draft state. In our case, the employee is unable to modify a line and resubmit the expense report.
This fix remove the readonly state on the expense line in refused state.
When using t-esc, if the value is False/not set, the element is not
added to the DOM. Therefore the page asked for feedback but never
actually displayed a textarea input.
Using t-att-value simply prefills the input.
Without this patch, the new-api/old-api adatpter will invert the
context and count attributes (takes always the context as last positional
argument). This lead to having the count argument being the context,
always returning the count of elements.
Commit 404ed0f788 tried to solve the
problem but only solved a part of it. Indeed, if the snippet child
has a bg color option but not a bg image option, the event propagation
stops in the parent handler, when it is too late.
Solution is checking that the event comes from the same element on
which the callback is attached to.
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)
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 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
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
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)
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.
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
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.
When a database is created, we are not auto-logged in to the new
database anymore because the login passed to the authentication request
is 'admin' instead of the one set in the creation form.
To fix this issue, we used the login parameter from the creation form
in the authentication request. We also set the login field to
required in the create database form view.
This bug comes from rev https://github.com/odoo/odoo/commit/903733a32
When anglo-saxon accounting is enabled and the valuation of a product is
'real_time', rounding errors might occur in the price difference between
the invoice price and the product price. It occurs when the product
price precision is larger than the accounting precision.
To avoid these rounding errors, we calculate the difference as the
difference between the price before update and the price after update.
opw-686730
- Activate the option "Track Lots or Serial Numbers".
- Set the outgoing process as 3-step one.
- Create a stockable product for which the tracking is "By Unique Serial
Number".
- Go to Sales > Sales > Sales Orders.
- Create a Quotation for the created product and confirm it. A picking
is generated but it is waiting availability.
- You are sure to have this product in stock so you force the
availability and assign the serial number (001) you want to transfer
in the operation lot details.
- Validate the picking. By doing this, it creates a negative quant in
the origin location (WH/Stock) and it creates a positive quant in the
destination location (WH/Packing Zone). The two quants are linked to
each other.
- Go to Inventory > Inventory Control > Inventory Adjustments.
- Create an inventory in WH/Stock for all products and set it in
progress.
- You want to correct the negative quantity you have so set the real
quantity of product B to 0.
- Validate the inventory and you get the following warning: "The serial
number 001 is already in stock.Otherwise make sure the right
stock/owner is set".
We should allow a quantity larger than 1.0 temporary, so it allows the
system to reconcile the quants.
opw-685825
category was changed to "Website" so it'd appear under the website
category in the store, but it needs to be "Theme" otherwise it doesn't
appear in the "Choose your theme" menu after installing website.
background and color snippet options
The background and color snippet options communicate so that if a
color is set while a background is already set, the backgrond is
removed. The problem is that the event propagation was not stop
so if a snippet had a background and one of its child set a color,
the background was removed.
Since 5a9e1af64 our guess_mimetype accepted a `default` named argument.
This commit fix the use of library used instead of our implementation, so
we don't get an error from an unexpected argument when having python-magic
installed on a given server.
Since python-magic functions always return a default mimetype:
- empty content: application/x-empty
- text content: text/plain
- binary content: application/octet-stream
the guess_mimetype default argument is not used with python-magic
implementations.
closes#13343
opw-687354
When an owner is defined on a quant, the current behavior is to to allow
only the owner to use it. This is restrictive for internal transfers:
when a quant is owned by Partner A, only a picking with owner Partner A
can select it.
The fix is to make things a bit less restrictive: when a quant is owned
by Partner A, a picking without owner or with Partner A as owner can
select it.
opw-687207
2 rules were defined with the same id thus only one was loaded in
database, resulting in missing read access on model
'project.task.history.cumulative'.
This patch fixes the ids of these rules and clarify their names
In the new API, default calls are supposed to return recordset
(even empty recordset), not bool values for relationnal fields.
If the table for this model was already present and if no l10n_x
was installed, no default value could be computed correctly for
existing entries. This caused a crash on install.
opw-683470
When we were trying to delete a stage in project where there were
some tasks, an error was raised because of the 'project.task.history.cumulative'
records that inherit 'project.task.history' which have a compute method on
on end_date.
To fix this, we set the 'compute' attribute to 'None' and the readonly
'attribute' to 'True'.
If you create an issue when `default_project_id` is set, the stage_id
is initialized at the lowest sequence of the stages of the project,
which is normal. However, when you change the project of the task,
the stage_id was not correctly reset. If you save at this time, you
add the selected stage in the project.
Also, the stage_id was not correctly cleared if you remove the project.
If you create an issue directly, the key `default_project_id` is not set
in the context. This key is used to compute the default stage of the
created issue. It is done by creating a domain. Unfortunately, the
domain is always filled with `[('fold', '=', False)]` and thus it
always returns a result that makes no sense when `default_project_id`
is not set. Worse, if you actually create the issue, the found stage
that was not in your project is now a part of it.
The fix is to return no result if the `default_project_id` is not set
in the context.
If you create a task when `default_project_id` is set, the stage_id
is initialized at the lowest sequence of the stages of the project,
which is normal. However, when you change the project of the task,
the stage_id was not correctly reset. If you save at this time, you
add the selected stage in the project.
Also, the stage_id was not correctly cleared if you remove the project.
Yannick Tivisse