| Age | Commit message (Collapse) | Author |
|---|
|
Task 2005940
account:
* Use stored compute methods instead of default for
{out,in}bound_payment_method_ids
* Track is_move_sent in the chatter
* Split 'Invoices' and 'Bills' in the smart button of payment form
* Because account.payment.method can be shown on the res.partner form,
we need to relax the security level to readonly for all users
account_check_printing:
* Add the preferred payment method for partners, with a related on
account move allowing to do a group by and doing payments in batch
* Add a constraint to forbid twice the same check number in the same
journal
* The amount in words is now readonly to prevent typos and mismatches
with the amount in digits
* Remove the field `check_number_int`. The check number is kept as Char
so that '000012345' is not displayed (and printed) as '12,345' but it
is parsed so that comparison and incrementation are possible.
closes odoo/odoo#56179
Related: odoo/upgrade#1669
Related: odoo/enterprise#12527
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
|
|
The current accounting tour is broken, this change will fix it.
Task id #2289610
closes odoo/odoo#55850
Related: odoo/enterprise#12389
Related: odoo/upgrade#1643
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
|
|
Only advisor (or more) can use resequence.
Task ID: 2297407
|
|
Task 2227389
The wizards for creating Accrual Entries and Transfer Entries are quite
similar. We are merging them as they share code and business logic.
Entries in the future should not be posted for both wizards, but set to
be auto posted instead.
|
|
- Make sure to have 'Billing' access rights
- Create an invoice
- Fully paid this invoice
- Try to unreconcile the newly created payment
=> You should have the access rights to do that
closes odoo/odoo#53785
X-original-commit: 5b2f9bac2a430b77637c28f4ee54ae66789ea116
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
|
|
Partner mapping is a new field defined on invoice matching reconciliation models. It allows defining a mapping between partners and regular expressions. When ran, on a statement line without any partner set, those rules use this mapping to assign a partner to statement lines without any one set, using the regular expressions to match the payment reference of the statement line.
It is important to note that the mapped partner will only be set to the statement line when the reconciliation is actually performed (so, when clicking the validate button, if the matching rule is not auto_reconcile = True), just like with the partner_map.
|
|
Task 2201948
*These actions were either unused or only used in enterprise modules.
The first ones have been deleted, and the second ones have been move to
the corresponding enterprise modules.
* account.fiscal.year: the whole model has been moved to enterprise
closes odoo/odoo#46110
Related: odoo/enterprise#8706
Related: odoo/upgrade#1083
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
|
|
The model account.setup.bank.manual.config (menu "Add a Brank
Account") was with the group account.group_account_user ("Show Full
Accounting Features").
Since 65530dfd6a04, transient models have ACL and are not accessible
if the user does not belong in the group.
The account.setup.bank.manual.config model is triggered via the server
action account.action_new_bank_setting instead of a classical
menu. It's also displayed in an onboarding step of account.
Because of this, the group must be relaxed (and not just adding a
group of a view/action)
In saas-13.2, 65530dfd6a04 made simply the wizard appears in readonly
but in saas-13.4, since 56a8c9e4311d24, trying to display a model on
which we do not have access produces and access rights error.
closes odoo/odoo#51330
X-original-commit: a4a2b8198d5d2d368e279929a5cdbcca0376d8ef
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
Merge account_analytic_default into account
Merge account_analytic_default_hr_expense into hr
Merge account_analytic_default_purchase into purchase
Prevent having to manually install default modules after activating analytics
closes odoo/odoo#50816
Task: 2182900
Related: odoo/upgrade#1186
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
|
|
In the same xml file (meaning one of the two rule is useless, or wrong
if giving less rights than the other).
Removing rules that had no impact will ease the understanding of
security problems, by reducing the number of interconnecting rules.
|
|
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
closes odoo/odoo#41485
Related: odoo/enterprise#7189
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
|
|
Following changes needing ir.model.access on transient models too.
Remove groups declaration on the action to move it to ir.model.access
when possible.
Rules are strict by default with no unlink access by default and high
priviledge asked. Adaptations may be needed later.
Write access is given as a wizard may need to be modified in case the
action triggers an error and the user has to correct a value
account*: use account.group_account_user for all transient by default
remove account.print.journal relic
stock*: use stock.group_stock_user by default
survey: survey user can send invitations
mail: allow any employee to execute wizards
additional verifications are made to ensure they are executed
only on the documents the user has access to you
give portal access to mail.compose.message as portal still does
some actions like posting messages on the forum
add ir.rule to avoid reading somebody else messages
increase the query count because of undeterminist count
crm: saleman for lead2opp, manager for massmailing
partner manager for actions linked to partners
avoid a write in test_lead_lost
sms: any employee can send sms
mrp: mrp user can execute wizards
give unlink access as making write during do_produce operation
base_import: employees can import files
delivery: stock user can deliver
event_sale: sale user can configure the wizards
event user inherit from sale rights
gamification: employee can give badge
google_service: resolve FIXME
hr: add specific rights
manager can set a plan according to group on button
anyone who can write on an employee can register a departure
hr_expense: set rights based on buttons
hr_holidays: an approver can make a summary report
hr_recruitment: recruiter can refuse a candidate
hr_timesheet: can use the wizard if can create a timesheet
l10n_eu_service: managers can create fiscal positions
mass_mailing: same group as on mass.mailing.list
membership: accountant can create invoice from membership
payment: accountant can create a link
as the source is an account.move
keep the payment.acquirer.onboarding.wizard to system user
only as it is called during company configuration
point_of_sale: PoS manager only can use wizards
never create closing_balance_confirm_wizard records
product_expiry: stock user has rights on stock.picking
product_margin: access from accounting menus
repair: same rules as for above models
sale: set ir.rule for self wizard only
add rule from model introduced in payment to add salesman group
sale_crm: saleman can create a quotation from a lead
sale_coupon: any saleman can generate coupon
add self ir.rule
sale_product_configurator: salesman can select product variants
snailmail: employee can send letters
website: designers can write on website
website_crm_partner_assign: same rule as group on action
website_sale: sale ACL as for payment.acquirer.onboarding.wizard
website_slides: anyone can send invitation
base: base.language.*: allow employee (cf lang_install)
change.password.user: can not read change password wizard of
other users
test.*: no access is needed
Courtesy of Damien Bouvy, William Andre and Antoine Prieëls for review
of acl
|
|
Task 2092079
Accounting firms that want to give access to their customers avoiding
mistakes and risks will love this profile that can't do anything
wrong... Maybe as well as companies auditors..?
closes odoo/odoo#39860
Related: odoo/enterprise#6576
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
|
|
|
|
The recent refactoring made at 30cf7bc798ddede8e610001146f4a76352aa582f introduces a new object for the different writeoff lines that could be created from a reconciliation model. Unfortunately, Billing users were forgotten during that refactoring which made them unable to read/use the reconciliation models anymore.
This patch grants them the Read and Create permission on the new account.reconcile.model.line object, as they already have to the reconciliation model.
closes odoo/odoo#42009
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
|
|
Task 2046908
Instead of having all the fields duplicated with second_*, we have now a
o2m allowing us to
* have more than 2 lines
* reduce duplicated code
* fix bugs and add features at only one place
We also remove the computation of writeoff and suggestions from the
client side as some code was 4-upled before (twice in in client and
twice in server side). The logic is now only at one place.
closes odoo/odoo#38119
Related: odoo/enterprise#6324
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
|
|
- Introduce a new account.tax.report object
> Tax report lines now refer to a tax report, and the tax report to a country
- Tax report lines can share tags accross reports within the same country
> To support the cases where some report is a simplified version of another one: some of its lines can be computed in the same way as the 'bigger' report.
> This is done by giving the same tag_name to the tax report lines, and the same country_id to their parent report.
> Full support for tag name modification, and the way it impacts the shared tags (sometimes, we can overwrite them all, sometimes we must delete them, sometimes, we create new tags to replace them on some report lines).
- Support copying tax report (and the lines/tags linked to it), so that it is possible to duplicate them and change the country set on the duplicate for use in another country (coopying is way better as replacing in place, as we don't keep any link to an xmlid, and still allow using the original report in the original country it was created for).
- Make all l10n* modules compatible with those changes
closes odoo/odoo#38964
Related: odoo/enterprise#6217
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
|
|
Task 2092104
Accounts group Hierarchy should be automatically well done without to
have to specify the parent (based on the account group CODE)
Before, we had to set all the accounts in the correct groups manually
and it was cumbersome.
Now:
* No need to fulfill account group parent
* No need to fulfill account group id on account
We can still change the groups if there are exceptions; the groups are
only set at create and write time.
|
|
As the group_account_invoice doesn't have the access rights to unlink the
account.partial.reconcile/account.full.reconcile, there was impossible for
the user to undo a reconciliation.
closes odoo/odoo#40934
X-original-commit: 0288adb0c315a1da63fe7e2d9b1f586ad6c9555b
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
|
|
When the only app installed is 'invoicing', people were getting an error while trying to generate the account.reconcile.model from its template. Could have done it in sudo(), truth is: account.reconcile.model object is not security critical
closes odoo/odoo#37622
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.
|
|
(beaa30a3d1843de43a45f419bfbc1bfa7613a920)
This commit merges the following models
* account.invoice and account.move
* account.invoice.line and account.move.line
* account.voucher and account.move
* account.voucher.line and account.move.line
It was the opportunity for a big cleanup of the code, so it also restructures the whole account module, its different models/fields, the tests etc. for a better world and a better code readability.
==== Rationale ====
The rationale of this huge change is that we want journal entries / invoices to be easily edited, and changes reflected in the other model. It's a HUGE feature and very strategic for the fiduciary companies. For example, changing the account of a journal entry needs to be automatically reflected on the related invoice.
The same reasoning applies to sale/purchase vouchers.
==== Changes made in features =====
When creating an invoice, you are now creating a journal entry directly.
--> The object account.invoice no longer exists.
In the same fashion when creating an invoice line, you're now adding journal items directly in the journal entry representing the invoice. If this invoice line has some tax, it may create additional journal items as well.
--> The models account.invoice.line & account.invoice.tax no longer exist
Identically, when creating a sale/purchase receipt with its lines, you are now creating a journal entry directly and there's no more usability difference between encoding a receipt or an invoice.
--> The object account.voucher no longer exists.
--> The object account.voucher.line no longer exists.
--> The whole account_voucher module no longer exists.
Positive side-effects coming from these changes are
* draft invoices/bills/sale or purchase receipts now create a draft accounting entry. Validate these objects now simply post its journal entry. That means that draft invoices/bills/sale or purchase receipt can straightforwardly be included in reporting or budgets.
* opening a journal entry in form view will now always open the correct view: if it's a sale/purchase journal entry we will have a customer invoice/vendor bill view or a sale/purchase receipt view, whatever the menu we're coming from.
* code & business logic simplification. It is also condensed in a single place instead of being partially duplicated on invoices, vouchers and journal entries.
There should be no feature loss, except the one allowing to group multiple journal items together based on the same product during the invoice validation.
==== Changes made in models =====
* account.invoice: model removed. Instead, now use account.move with following mapping
field (account.invoice) field (account.move)
----------------------- --------------------
name invoice_payment_ref
number name
reference ref
comment narration
user_id invoice_user_id
amount_ total_company_signed amount_total_signed
residual amount_residual
state state + invoice_payment_state /!\ selection changed
date_invoice invoice_date
date_due invoice_date_due
sent invoice_sent
origin invoice_origin
payment_term_id invoice_payment_term_id
partner_bank_id invoice_partner_bank_id
incoterm_id invoice_incoterm_id
vendor_bill_id invoice_vendor_bill_id
source_email invoice_source_email
vendor_display_name invoice_vendor_display_name
invoice_icon invoice_vendor_icon
cash_rounding_id invoice_cash_rounding_id
sequence_number_next invoice_sequence_number_next
sequence_number_next_prefix invoice_sequence_number_next_prefix
'invoices' subset of account.move can be accessed by using the selection field 'type' or one of the many helpers like is_invoice()
* account.move: now has a valid state 'cancel' that has to be excluded from all business logic
* account.move: field 'amount' renamed into 'amount_total'
* account.move: field 'reverse_entry_id' renamed into 'reversed_entry_id'
* account.move.line: now has a field 'display_type' that has to be excluded from all business logic, in order to support invoice layouting
* account.invoice.line: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.line) field (account.move.line)
---------------------------- -------------------------
invoice_id move_id
uom_id product_uom_id
invoice_line_tax_ids tax_ids
account_analytic_id analytic_account_id
'invoice lines' subset of all account.move.line from a journal entry can be accessed by using the boolean field 'exclude_from_invoice_tab'
* account.invoice.tax: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.tax) field (account.move.line)
--------------------------- -------------------------
invoice_id move_id
account_analytic_id analytic_account_id
amount price_unit
base tax_base_amount
'tax lines' subset of all account.move.line from a journal entry can be accessed by using the relational field 'tax_line_id'
* account.invoice.confirm: model removed. Instead, now use the 'post()' function of account.move
* account.invoice.refund: model removed. Instead, now use account.move.reversal to reverse the entries with the same options as we had for invoices
* account.voucher: model removed. Instead, now use account.move of type in ['out_receipt', 'in_receipt]
* account.voucher.line: model removed. Instead, now use account.move.line
==== Changes made in functions ====
* on account.move, method _run_post_draft_to_post() renamed into _autopost_draft_entries()
* on account.move, method action_account_invoice_payment() renamed into action_invoice_register_payment()
* on account.move, method action_invoice_reconcile_to_check() renamed into action_open_matching_suspense_moves()
* on account.move, method _get_domain_edition_mode_available() renamed into _get_domain_matching_supsense_moves()
* on account.move, method _get_intrastat_country_id() renamed into _get_invoice_intrastat_country_id()
* on account.move.line, method _get_domain_for_edition_mode() renamed into _get_suspense_moves_domain()
* in account.bank.statement, contextual key 'edition_mode' renamed into 'suspense_moves_mode'
Was task 1917430
|
|
This table tracked standard price changes.
It was used to compute the valuation at date in AVCO and standard
through `get_history_price`.
The next commits will introduce the stock valuation layers, separating
the valuation from the stock move. As a valuation layer will be created
when a standard price is updated on the product or when a stock move
impacts the valuation, the information from this table will be
duplicated.
We don't plan to adapt `get_history_price` to work with the valuation
layer since the valuation report at date and today will be the same: a
grouped list on the valuation layers with eventually a domain on the
date.
task-1875873
|
|
- Add repartition lines on taxes
- Link account tags directly to account.move.line; remove the tag_ids field from account.tag
- Add a new report engine dedicated to tax reports, directly generating account tags. It is called as an alternate mode of generic tax report, with a dedicated "Use tax grids" toggle.
>> The biggest change lies in the way the new tax report computes its values.
Everything is now aggregated directly using the tags set on the account move lines. Thanks to that,
modifying the configuration of a tax today will not impact the report for the previous periods anymore.
This is a big improvement, as it means the report will keep on reflecting the values that were submitted
to the state before, whatever the configuration change.
- Add an audit char field to account.move.line telling with tax grids are impacted by the line, with the corresponding amount
- Modify the behavior of cash basis taxes: the cash basis account is now used as the transition account, while the regular account given in tax declaration is used to store the final entry (it was the opposite before)
- Modify every l10n_* module in order to keep them consistent with these changes
closes odoo/odoo#32833
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
|
|
It can be useful to be able to select several journals in 1 click in the
financial reports
Task: 1857934
closes odoo/odoo#26711
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
|
|
In multi-company, create a new company C.
Set the chart of account in settings, save.
You get an access right violation on account.reconcile.model.template
because you need account_user.
Since this group is supposedly dependent on another module,
a user is supposedly never in this group without that module.
Obviously, this should supposedly not happen.
opw 1938539
closes odoo/odoo#31003
|
|
|
|
|
|
|
|
removed the access right that was granting the read access on invoices to any internal user, because there's no reason to do so.
Fixes #28486
|
|
|
|
Accountants should be able to edit, create or unlink tagsµ
|
|
This will allow to use the same core for all intrastat reports and benefit from the dynamic financial reports engine.
Incoterms have been move to account, as we want to provide a light intrastat report for people not having the stock app installed
Was task: 35850
Was PR #23805
|
|
In order to improve the fiscal year management, we allow the user to define custom fiscal years
using the account.fiscalyear model.
Was task: https://www.odoo.com/web#id=39878&view_type=form&model=project.task&menu_id=
Was PR #20936
|
|
Was part of PR #19820. Courtesy of Vauxoo
|
|
In some countries, we need to be able to make appear on an invoice a rounding line, appearing there only because the smallest
coinage has been removed from the circulation.
For example, in Switerzland invoices have to be rounded to 0.05 CHF because coins of 0.01 CHF and 0.02 CHF aren't used anymore.
Was PR #15231
Was task 30904
|
|
As already done for sale, customer portal for account is moved to account
module directly. Account now depends on portal module and website module
is not necessary anymore to display the account customer portal.
|
|
This information will be used by account.report to render accounts in hierarchies.
Was PR #17367
|
|
When the 'Invoicing' or 'Accounting' module is installed without the
module 'Sales', only the admin user can create products in the database.
The expected behavior is that any 'Accounting Adviser' should be able to
manage some products in Odoo.
To allow 'Accounting Advisers' to manage products, we add them the CRUD
rights on 'product.product', 'product.template' and
'product.price.history'
opw-703610
|
|
managers
PURPOSE
=======
A lot of customer are struggling with the fact that from the SO lines their users sometimes type too fast the product name and end up by creating or selling products that are simply mistakes.
Only the sale/manager, subscription/manager, purchase/manager, mrp/manager, warehouse manager, event/manager, pos/manager and invoicing person should have access rights to create and update products.
SPECIFICATION
=============
Remove create and write rights on product_product, product_template and product_price_history for stock users and move these rights to the subcited apps managers
|
|
In details:
* account.operation.template object renamed into account.reconcile.model
* account.reconcile.model.template object created
* added some records for l10n_be
Was PR 11230
|
|
Purpose:
Having the res_group defined in base and sales_team auto installed
with mail doens't make sense.
- Move the empty res_config class and the related view from
base_setup to sales_team (base_setup only contains the 'General Settings'
model and views
- Move the 'sale' related content from product to sale module (Access rights,
menuitems,...)
- Set sales_team at autoinstall False. The module is installed when needed by
crm or sale for example
- Set sales_team as a dependency of voip. (Access rights defined for configuration
purpose)
- Set sales_team ad a dependency of subscription (Access rights issue too)
[FIX] account: move some ir.model.access to sale module
[FIX] payment: Move some ir.rule to website_sale
[FIX] stock: move some ir.model.access rule to sale_stock
[FIX] project: Move some ir.model.access rules to crm_project_issue
[FIX] mrp: Move some ir.model.access rules to sale_mrp
[FIX] calendar: move some ir.model.access rules to crm
Rename xmlids accordingly. Example: 'base.group_sale_manager' becomes
sales_team.group_sale_manager.
[ADD] sales_team: See own documents => See only his sales team
Moved the "User: Own Leads Only", "User: All Leads" and "Manager" groups from sale and crm
into sales_team module. Add the record rules so that user can see only his Own Sales Team
if "See Own Leads" is sales right and can see all sales teams if he is having sales rights
of "See All Leads" or manager.
|
|
This branch need more testing instead of doing 10 fixes. A lot of issues are occuring
when installing modules in different orders.
This reverts commit fa6e415cdb23ce9494487ed672792186157b40e0.
|
|
This reverts commit 6d33eb037c4450ad12fb142aa8e0cb7de3e6b7c2.
|
|
The groups group_sale_salesman and group_sale_manager have been moved
from the base module to the sales_team module.
|
|
Purpose:
Having the res_group defined in base and sales_team auto installed
with mail doens't make sense.
- Move the empty res_config class and the related view from
base_setup to sales_team (base_setup only contains the 'General Settings'
model and views
- Move the 'sale' related content from product to sale module (Access rights,
menuitems,...)
- Set sales_team at autoinstall False. The module is installed when needed by
crm or sale for example
- Set sales_team as a dependency of voip. (Access rights defined for configuration
purpose)
- Set sales_team ad a dependency of subscription (Access rights issue too)
Rename xmlids accordingly. Example: 'base.group_sale_manager' becomes
sales_team.group_sale_manager.
|
|
-because If a user wants to have a report of all its invoices, he/she has to install the full accounting app.
-Add access rights for Reports.
|
|
anything new but this concept seems to be a legal requirement is some countries, hence considered as a fix. A different patch for v9 has been pushed at 395c4bdc691528503c6dd4168fcda40d0aecc84d, to wrap this change into a module
|
|
(account.bank.statement.line)
|
|
Issue: without access on account.partial.reconcile model, a billing user can create
an invoice, but not validate it.
|
