The parent commit allows to select a specific interval for any
date or datetime field in the groupby menu. This makes some filter
akward, for instance "Order Month".
Accordingly, we have rewritten the string and help attributes in
search views archs and removed groupbys related to the same field
(that would have become redundant).
With this change,
* some modules are now set to be automatically installed by default
* the setup bar of accounting has been changed in order to allow more easiliy the configuration of bank accounts/journals (and the step to oversee the opening entry has been removed)
* the kanban view in the dashboard has been enhanced (mostly for bank journals, but not only)
Was task: 32668
Was PR #23049
Allow the user to set taxes on lines when creating manually a new journal entry, and tax lines will be computed automatically thanks to an onchange based on new unstored fields.
Was task: 33802
Was PR #19029
This allows to set up a mail alias per purchase journal. Then share that email address to your supplier, or use it internally to forward the vendor bills received by mail, to automatically create an empty vendor bill with the mail attachments linked, and the partner might be filled if the source email matches a supplier.
Thanks to the document preview on the side, it's now super easy and super fast to copy the vendor bill info from the received PDF into the account.invoice object. This would eventually be improved later on (IAP).
Was task: 37703
Was PR #22158
It was very confusing for the user to distinct account.payment and payment.transaction. From now on, the transactions are
technical objects and, in the backend, we only refer to it in log messages (Front end will be adapted in the same fashion
later on). They are hidden in debug mode in accounting\configuration\payments as their purpose is now purely technical/log
This commit also aims to reduce the gap between the accounting app and the transactions: account.payment objects are
created/validated upon completion of transaction.
To ease the capture/voiding of pending transactions, the related buttons are now displayed directly on the SO/invoice
instead of the transactions.
Was task: https://www.odoo.com/web#id=35857&view_type=form&model=project.task&action=333&active_id=967&menu_id=4720
Was PR #24043
[FIX] add domain based on journal to payment tokens
Was opw: https://www.odoo.com/web?debug#id=1828206&view_type=form&model=project.task&menu_id=5200
* budgetary position nor analytic account aren't required anymore (although one of the 2 have to be given)
* by extension, the computation of practical amount is not either based on the analytic lines or the account.move.line
* usability improved (for eaxmple: there's a button to open the list of items on which the practical amount computation is done)
* addition of a pivot and graph views of the budget lines
Was PR: #22342
Was task: 31995
The residual amount of a customer invoice or a credit note is displayed
in the same way in the portal view. This can be confusing for the end
user since there is no way to distinguish both.
We display the residual amount as negative in case of a credit note.
opw-1841432
- Go on the partner form view
- Click on the stat button 'Invoiced'
- Create an invoice
The partner is not filled in.
Overlook of 1f277a3572
opw-1839867
* when refunding an invoice/bill with the option 'modify', it now opens the draft document in form view (chatter reworked for more clarity)
* payments list views are now using filters instead of domain, so that user can easily find back any payments (also transfer that haven't their dedicated menuitem)
* when clicking on a ling to create a new payment from the dashboard, the form view is directly open instead of the list view
Was PR #23402. Was task 58392
The reified view on the res users will be dropped in the following commit.
The previous commit adds support to define each group as a computed field on the res users.
This commit defines:
- A boolean field for each 'isolated' res.group, i.e. a group in the hidden category.
- A selection field for each 'Application' res.group, i.e. a group in a application category.
Example:
- The group to manage pricelist in sales becomes a boolean field
- The groups project user/manager become a selection field
This adds the possibilty to select another account.invoice object in a vendor bill or credit note, to automatically copy its lines.
When the purchase app is installed, the same field can be used for auto-completion and users can choose between vendor bills or purchase orders (preferably PO)
Co-authored-by: dat@openerp.com
- Create a user A with group `group_sale_salesman` but no Accounting &
Finance group set
- Create and validate a SO, create the invoice
- With another user B, pay the invoice
- Print the "Invoices" with A
An access error occurs.
The error is due to user A not having the rights to see the payments.
We set a group on the corresponding report to avoid a user without
proper rights to print it.
opw-1837845
We now display all the existing currencies (even the unactivated) instead of a link to activate more of them, and upon the save we make sure to activate the selected currency if it's not yet the case. That's better from a point of view since it avoids jumping off of the screen then come back to make this setting
Unlike LESS, SCSS variables are not lazy loaded. Our system has thus
to be updated. This commit creates new templates which are t-called
in assets bundles (to replace the old less_helpers template):
- web._assets_utils: regroups the mixins and functions which *can*
(and so should) be available in every asset bundle
- web._assets_primary_variables: regroups the variables (or mixins
used as variables) which *can* (and so should) be available in
every asset bundle
- web._assets_secondary_variables: same as above but provides an
environnement where all the 'primary' ones are accessible. This is
for example useful to handle the community/enterprise split:
// Community primary variables
$o-pink-color: pink; // enterprise color
$o-brand-primary: blue;
// Enterprise primary variables
$o-brand-primary: $o-pink-color;
// Community secondary variables
$o-my-darker-primary: darken($o-brand-primary, 5%);
=> If there was only one variable template, enterprise edition would
have been able to define its primary color at the end but the
darker primary would not have been updated. Using the "!default"
system and putting enterprise definition above would not have
solved the problem as the $o-pink-color would not have been
accessible.
- web._assets_backend_helpers: regroups the variables, mixins and
functions which *can* (and so should) be available in the backend
asset bundle only. This is especially (only?) useful for bootstrap
variables overriddes.
- web._assets_frontend_helpers: regroups the variables, mixins and
functions which *can* (and so should) be available in the frontend
asset bundle only. This is especially (only?) useful for bootstrap
variables overriddes.
Note: bootstrap variables are not accessible in any of those anymore.
If you have variables that should depend on bootstrap, you have 3
solutions:
- Find another way: your variable is probably useless, use bootstrap
variables directly or create a variable that will influence the
value of bootstrap variables. E.g. instead of declaring:
`$myvar: $bootstrapvar * 3`
and using $myvar alone, declare:
`$myvar: 3` and use `$myvar * $bootstrapvar` where needed.
- Declare a copy of the bootstrap variable and use that one. In that
case, you should also force-set the real bootstrap one to be sure
they match (this should be done in appropriate templates mentioned
above). E.g.
```
$o-boostrapvar: 5;
...
$boostrapvar: $o-bootstrapvar;
```
- Set your variable to null and set it to your bootstrap expression
in the file you will need it (where bootstrap variables are accessible)
without forgetting to add the !default flag to allow overriddes.
```
$myvar: null;
...
$myvar: $bootstrapvar * 5 !default;
```
This commit also partly changes the variable names to follow the
convention:
$o-<app_id>-<name> where 'app_id' is the current's app name or a
meaningful unique identifier ("theme" for all themes for example, as
no multiple themes can be installed).
During first scss convertion, classes called as mixins were changed to
an @extend instruction which was the best approximation given the fact
there is no equivalent in sass to do that. The problem is that the
instruction is slowing the scss computation a lot and might also break
the style in unexpected ways because of the complex unwanted selectors
the instruction induces.
This commit removes the need of extends. This is done case per case.
Sometimes this involves adding classes in xml, sometimes to change the
style a little, ... The button rendering refactoring which was made
at the start of the LESS to SASS merge was also done in prevision of
this.
After this commit, sass computation is like 5-6 times faster than less
computation while it was like 10 times *slower* before this commit.
This commits adds a field on bank statement that will be used to force the creation of the accounting entries at this date instead of the bank statement date (in the same way than on invoices). This is useful if the accounting period in which the entries should normally be booked is already closed.
This field is only visible in debug mode.
Was PR #22441
Was task 46892
As for commit 3f975f9769, the partner_type field is readonly and cannot be modified when not in draft.
It makes the form invalid, so form buttons cannot be used, e.g. to access the journal items, etc.
Before this commit, a partner in a company could have a fiscal position belonging
to another company
Namely, the search view on the field property account position displayed every fiscal position
This could create problems afterwards, when managing an invoice from a restricted rights user
(with an access right error raising)
After this commit, we soflty constrain the choice of the fiscal position to the ones
belonging to the same company of the partner
OPW 1833848
OPW 1827831
closes#24056
An empty div `o_attachment_preview` is added in expense and vendor bills form
views. It will be used as a container to preview the attachment.
The actual behaviour will be implemented in another commit.
Task 40663
When not draft, the partner_id field is readonly and cannot be modified
anyway, but it makes the form invalid, so form buttons cannot be used,
e.g. to access the journal items, etc.
Correct account invoice line form view so studio doesn't fail on
something that doesn't seem really correct (and somehow worked thanks
to pyeval implementation or the override from another view type).
opw-1826254
opw-1830171
closes#23997
Mathieu Duckerts-Antoine