This reverts commit 7642754122.
The reason is that we finally decided to implement that in another way and we want to avoid people start using this feature as it would be replaced in next saas. Yes, I know, that sucks.
New task ID: 1823153
- One need to first enable this from Accounting Settings to use this feature
- This feature works for Vendor Bills which are validated/paid
- Once activated, user can see one option in Vendor Bills to set particular record to be recurrent document and can define the recurrency period. This will automatically create draft documents(by mean of Scheduled Actions) as per recurrency configuration.
Was PR #21411. was task 34884.
1. Create a new user with all the permissions as manager (or at least
Accounting) except Inventory
2. Login and then go to Invoicing --> Settings
3. Do a minor change, save
An access error occurs.
Since the settings of all modules are smartly loaded in v11, it now
implies that a user must have extra manager access rights to be allowed
to save them. We could have kept separate actions for each setting page,
but we would have missed the fun of access errors.
Anyway, security-wise this is not an issue to force the manager groups
since a user with 'Settings' access rights can change his own rights.
It's just very annoying. Or fun.
Complement of aa65a46fc5Fixes#21766
opw-801210
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
Purpose
=======
We want to clear the accounting access groups when only the Invoicing application is installed as follows:
If only Invoicing is installed, we should only have 2 groups: `Billing` and `Billing Manager`
If Accouting and Finance is installed, we should have the current groups: `Billing`, `Accountant` and `Advisor`
Specification
=============
1/ If we have only Invoicing the should have the following hierarchy:
group_account_manager (Billing Manager) ---Implies---> group_account_invoice (Billing)
group_account_user (Accountant) is a technical group out the Accouting groups hierarchy
2/ If we have Accouting and Finance installed, we should then have:
group_account_manager (Advisor) ---Implies---> group_account_user (Accountant) ---Implies---> group_account_invoice (Billing)
The reason we want to keep the group_account_user is that we will hide the accouting fields (account_id,...) with this group, allowing the consultants to show the accouting related information on support.
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.
Purpose
=======
we use to make proforma invoice to get payment before the creation of the real invoice. In the current odoo, the proforma state is too late. Because you have to confirm the SO to generate the draft invoice and so the proforma. But, if you do that, you have generated a subscription or a delivery order in the mean time. A proforma is actually a quote. In old ERP they used to make proforma to send a quote and don't generate invoice number.
Specification
=============
- Remove everything related to Proforma from accounting
- Remove the configuration of pro-forma from account setting
- Invoice form, remove "Pro-froma" button, stage, report title
- Add proforma configuration option in sales setting under "Quotation and Sales" section
- In quote/sale, add Pro-forma under Print
- A pro-forma is a quote, but the title of the report is Pro-Forma and not Quotation
- button (secondary) on quotation form "SEND PRO-FORMA" to send proforma by mail attached with related report.
- button
- mail template
- when preparing a quotation this button is visible but if even one invoice this should be invisible (as confirming SO doesn't generate invoice currently)
This record rule added in the below revision:
1950fc4216
has been removed for an unknown reason during the account refactoring
c04065abd8
Without this rule, a user can see invoices from other companies
through the invoices analysis.
opw-705718
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
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
Add a link in the general settings to access easily the default_user form view in order to modify the default access rights
The default_user manager rights declarations in all the applications have been move in a noupdate="1" definition to avoid the manual configuration overwrittings
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 fa6e415cdb.
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.
Coming from a bug in web_settings_dashboard. Invited user didn't have any rights
when created from the dashboard, which was leading to an error.
This bug leaded to a new discussion. Better to have basic employee having user
rights for all main applications. For bigger entreprises there is an admin that
will carefully remove extra rights, if necessary. The target is small businesses,
it makes sense that every way to create a user gives the same result.
In conclusion, each new user has a full access to the applications by default
How is it implemented ?
We added an inactive default user which original access right to the groups
'base.group_user' and 'base.group_partner_manager' in base. Each
application will extend the default user's access right by adding the maximal
access right for this application.
On user creation, we will use by default the 'group_id' field from the default
user. We will in the same time remove the ugly 'default_groups_ref' key which
was passed sometimes in the context for some fields in some views, and sometimes
nothing.
So, the user can modify the access rights for the default user, but he should be
aware that removing project user access rights for a default user will prevent
a *created on the fly in a task* user will not be able to access the task.
Major changes:
- No use of UoS anymore
- No analytic journal (journal_id) on account move lines
Reason: complete rewrite of the Sale module.
Responsible: fp, dbo, nim
Yannick Tivisse