This fix renames filters in purchase from Invoiced (resp. Not Invoiced)
to Received Bills (resp. Waiting Bills) to be consistent with the states
of the Purchase Orders (i.e. 'Waiting Bills'). The erroneous tooltip of
the Bills Received was also corrected.
In procurement form view display a Purchases stat button that redirects to
the purchase order. It opens the PO form view. Note that Purchase Order field
in Extra Information is left untouched. It is just a shortcut to ease
usability.
Publish buttons appeared in list view item in /shop with commit
5a5dd1e100.
They however never worked for some reasons:
* The publish buttons were unclickable as the around style was badly
implemented: the section title was over the publish button
* Even if it was clickable, the publish button handler had no prevent
default, thus it submitted the form it is in -> crash when no cart
button or added to cart on click on publish button if there was a cart
button...
Note: the style should be reviewed in next versions, this commit, as
a 9.0 fix, fixes the style with the minimum code and so that it does
not break any theme.
This reverts commit 7e6ad941cf.
The domain makes clear that the location to be chosen in is among the children of the location zones chosen in the picking. That way, if the stock would be calculated in the past (e.g. also for the stock valuation report), the system is going to think it is maybe still internal, while it went out, ..., so those domains are crucial.
It is already defined as a payment method (subtype=inbound) and that's what we want. No need of adding 'electronic' in 'payment_type' selection (that crashes if we select that, btw) and 'payment_method_id_code' is a duplicate of 'payment_method_code'.
'Project > Reports' menu show 'Tasks Analysis'. But
if you install project_issue, or rating_project, some
children menus are added, making 'Tasks Analysis'
invisible.
Trying here to set the same order for issues, ratings,
forecast as in other menus, labels and kanban card.
When you create a leave, you first set the start date. The date widget triggers
and automatically sets you at today, which triggers the onchange and puts the
end date at today + 8 hours. You then set your start date in the future
-> invalid dates because start date > end date.
This commit removes the onchange verification of the dates, because almost
everyone gets the above problem and because it is redundant with the sql
constraint that triggers anyway when you try to save with invalid dates.
a random ensure_one() was added during the migration causing an error when
modifying portal access management for partners with more than one contact.
Removing it.
That bug was introduced when removing the invoice workflow, where a call to action_invoice_cancel() has been used instead of action_invoice_reopen() which does slightly different things, as you can imagine.
This fix prevents from giving the reason of the refund to the draft invoice created if you select the 'modify' option when refunding an invoice, which now keeps the description of the original invoice.
This is a backport of saas-13 commit a9bd9ab160.
mail/view controller is a generic controller that redirects the user to a
given view, depending on the record and the user. Users may be redirected
to the backend form view, or to a website view. This is done notably by
calling get_access_action method that gives the action to perform (act_window
or url).
Previously this method was called using SUPERUSER. However it was therefore
impossible to know who the user was. This method is now called using the
current user. Various overrides of get_access_action have been updated to
add some logic and access rights check directly in the method allowing
more fine-grain behavior of the access action.
Commit 3c98c78fc7 added the feature to be proposed redirection
after a click on a menu link in edit mode. This however applied to main
direct link in the menu and not sub-ones in sub-dropdowns. This commit
fixes this.
As the <strong/> tag which surrounds the "Use this tag" sentence also
contained a <a/> whose href is a computed one (t-att-href), the strong
was not able to be edited.
Because 0% taxes will appear in the account.invoice.tax object of the invoice and the account, if null, will be the expense one which is confusing.
Because 44000 is use as everyone as payable account, so removed duplicated 'Fournisseur' account
tdi-odoo