This commits adds kanban view for the 'Generated Documents' for better
readability on mobile devices. Also, for consistency, this commit
adds 'Upload' button on the invoice kanban view as well.
Task-ID: 2152183
Task 2146469
Rework the name computation:
* It doesn't use ir.sequence anymore
* It is an editable computed field
* Add a renaming tool
This allows the user to tweak the sequences more easily than having to
get through the ir.sequence settings.
The sequence depends on a parameter of the journal: continuous, montly
and yearly restart of the sequence. Everytime a new period is started,
try to make a pattern form another period.
The incrementing is done by taking the previous name, ordered
lexicographically, splitting it by taking the digits at the end, adding
1 and re contstruct with the prefix.
** This means there could be cases where the prefix has a big importance
on the next number. For instance, if you have
INVOICE/2019/0001
INVOICE/2019/0002
and then rename the last one to INV/2019/0002, don't expect the next
number to be INV/2019/0003. It will be INVOICE/2019/0002 (again) because
the highest number was INVOICE/2019/0001.
You will then end up with
INVOICE/2019/0001
INV/2019/0002
INVOICE/2019/0002
closesodoo/odoo#41485
Related: odoo/enterprise#7189
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
This wizard also reconciles automatically entries done on reconcilable accounts. It can hence for example be used to "move" the balance of a receivable account into a payable account (or the opposite), using the generated transfer entry to do as if the receivable and payable accounts were directly reconciled together.
[IMP] account: display 'P' as matching number when account.move.line objects are partially reconciled
For this, we introduce a new matching_number field, used in account.move.line's tree views instead of full_reconcile_id, which used to be shown directly.
Was task: 2037318
closesodoo/odoo#39415
Related: odoo/enterprise#6544
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Task 2034073
The reconciliation widget is now entirely part of the enterprise version
as it is an advanced accounting feature
closesodoo/odoo#38424
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Task 2008956
* Add the root of an account (first 2 digits/char) as a searchable model.
* Create a custom searchpanel for this account root on account.move.line
* Add the account_root searchpanel to the account.account view too.
Task 2041865
We want to show a hierarchy to ease the account type selection (hack in the select widget)
BALANCE SHEET
ASSETS
Fixed Assets
Non-current Assets
Current Assets
Prepayments
Receivable
Bank and Cash
LIABILITIES
Equity
Current Year Earnings
Non-current Liabilities
Current Liabilities
Credit Card
Payable
PROFIT & LOSS
Income
Other Income
Expenses
Cost of Revenue
Depreciation
OTHER
Off-Balance Sheet
closesodoo/odoo#36170
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The onboarding modal for setting up the few base fields of a company
has now been moved to a wizard
It is accessible from the general settings, but also in the onboarding
section of sale and account modules.
The following company settings are editable with that wizard:
- Set report **layout**:
The user can chose the overall look of the report. The current choices
are : *Standard* (default), *Background*, *Boxed* and *Clean*.
- Set company **logo**:
Changes the company logo.
- Set report **colors**:
The user can set the primary and secondary colors of the report through
a newly added widget allowing to pick a custom color.
When changing the **logo**, colors are automatically set to its most dominant
colors.
> A "Reset colors" button also triggers the color calculation.
- Set report **font**:
Changes the overall font of the report. Only Google Fonts are used
for enhanced compatibility.
- Company **tagline**, also called "header"
- **Footer**
- **Paper format**
- Report **preview**:
A mockup of a final report
Automatically updates when changing **layout**, **logo**, **colors** or **font**
Co-authored by: Julien Mougenot <jum@odoo.com>
closesodoo/odoo#33863
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
As we now have a new debug mode 'tests' which load a new asset bundle
containing tour-test files, we moved those files to a new folder hierarchy.
That will clean the .js files trees.
Also, those files should be included in the new asset.
Basically, the .js tour files (not test) should be inside /static/src/js/tours
while .js tour test files (test=true) should be inside /static/tests/tours next
to QUnit tests, inside a tours folder.
+ test_new_api: don't run the test in debug assets
task-1934445
Comes with https://github.com/odoo/enterprise/pull/4281Closes#33213
Some variables were placed at the beginning of the backend helper.
While it was working, the normal convention is to place them at the
end of the variables helper.
closesodoo/odoo#28203
Purpose
=======
It's way more complicated than the dedicated import mechanism on the dashboard
NB:
There are still no way to hide the import button in a generic way.
This kind of ugly hack has already been done in https://github.com/odoo/enterprise/blob/master/sign/static/src/js/sign_backend.js#L53
This should be removed as soon as such a mechanism arrives.
TaskID: 1861619
Purpose
=======
The only module that was supposed to work without the accounting menuitems was
the ecommerce. Now that the ecommerce wants the accounting menuitems to be
visible, this module makes no sense anymore.
Specification
=============
Remove the account_invoicing module and move the code to account.
The goal is to be able to more easily create section and notes on sale order, invoice, and quote.
================================
Problems of the existing feature
================================
The problematic part in the existing feature was that the same section had to be defined again and again for every line, instead of being defined only once where it needed to be. There was also no easy way to move them. Those concerns are solved here.
Moreover, due to the complexity of the feature, it was hidden by default, requiring a setting and multiple overrides. The new feature is simple enough that it will always be present.
==================
New implementation
==================
Sections are lines solely used for display purpose, there is no business logic attached to them. They will show as a nice header at the top of the section, and a subtotal at the bottom of the section.
We also take the opportunity to add notes, which are just like sections except they are displayed differently and don't include a subtotal.
=========
Reasoning
=========
We decided to implement it this way, as opposed to creating a proper section model, because it creates less changes in the code.
Creating a intermediary section model between the sale order/invoice/quote and their lines would have required to rewrite the entirety of the code associated to them. It would also have required to create a new JS widget to handle on the same view a double-level One2many (or a One2many + group by).
The current solution is much easier because it just requires adding 2 buttons, 1 simple field on the corresponding models which even has a NULL default value, and making some business checks (don't apply business to section/note).
We tried our best to impact as less as possible the existing models. Notably we didn't want to add any extra field if this was avoidable. This also makes the migration easier.
No matter the implementation choice the views/reports had to be updated to display the sections and notes correctly, which has been done.
===========
Limitations
===========
The current solution has several limitations:
* since the sections don't have business logic, it's not possible to make any reporting based on them
* any business related to sections has to be computed on the fly by browsing in order all of the lines, notably the subtotal has to be computed on the fly at every display
- when sections are moved (drag&drop) on the back-end, the following lines that are part of the section are not moving with the section
===========
Technically
===========
The commit will:
* update the models to add the display_type field (along with related sql constraints to guarantee integrity)
* add new buttons at the bottom of the lists to allow creating section and note, along with the existing add a line/product button
* add some business checks to not apply business to section/note (product_id and account_id became non-required fields)
!!! The most likely cause of potential bugs introduced in this commit would be to have forgotten to add those checks on some places where they would be needed. This is tedious to check but fortunately easy to fix.
* update the views to display sections and notes correctly, also made various improvements/fixes to those views (notably to apply B2B/B2C setting more consistently)
!!! This is the second likely cause of potential bugs: if the updated views are inherited in a way that is not compatible with the changes. Or if we forgot to apply the changes to some other views. Again this is tedious to check but fortunately easy to fix.
Task #53996
PR #25209
*account_payment, l10_in(_sale), sale(_stock), web
With this commit:
The invoice preview in portal (/my/invoices..) is now the HTML version of the
PDF report.
The HTML preview is based on the invoice report to closely match what is
already done in Odoo.
The invoice preview is displayed in an 'iframe', it is mandatory since:
1. Reports are rendered as a separate page as it returns the whole page after
rendering, which has tag <html>, <head> etc
2. Reports are having their own layouts and their own assets that we we cannot
load in the page directly or it will break the website layout.
3. We can not use report template with t-call because internally reports are
using extra params like context_timestamp, company, DateTime, user etc which
is used in header/footer
--
There will be a chatter (as a modal) to display/see the history of the document
--
For responsive purpose, we use new tables with limited column (Description,
Quantity and Amount) for responsive purpose (small screen).
It also adds some bootstrap classes to reports for responsive purpose.
--
The 'Pay Now' button remains if you already paid with 'wire transfer'.
--
Add margin after the header and before the footer to look like the real printed
document, without alterating the real printed version
Task ID: 39876
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).
Add a setup bar on account's dashboard, so that the user can more easily enter the initial data of his Odoo installation, following the steps that are proposed to him.
Was PR #16864
Was task 32119
The account payment widget did not work at all, since we pushed the new
views. With this commit, we adapt the code to the new views (note: the
file account_payment_widget was renamed in account_payment_field).
* account, mass_mailing, sales_team
These view extensions have already been ignored for around two years.
The new views development is a great opportunity to remove them.
With our new views, we broke almost all JS code, including the
reconciliation widget, which was (and still is) dependant on the field
widget. With this commit, we rewrite and simplify the reconciliation
code. We also add some tests, to help with the maintenance.
Work done by CHM
Move the "dashboard_graph" widget to web.
It converts a Text field containing data to a graph. As it is a generic
widget, it can (and will) be used elsewhere.
- Use less instead of sass
- Use class name of both old and new designs
- Small CSS tweaks to support both designs
- JS compatibility fixes + a little cleanup
- The ctrl-enter shortcut only reconciles balanced entries
Adrien Dieudonne