PURPOSE
Lessen use of mail-specific calls and variables
SPECIFICATIONS
Use mail_new_test_user tool in tests, lessening use of mail-specific context
keys in tests.
LINKS
Task ID-2326281 (context keys use cleaning)
PR odoo/odoo#56631
PR odoo/enterprise#12707
X-original-commit: 910559c092dc7dfa00b91339a5423e16cd4668e1
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2301180
Purpose
Fix multi-company access issues following the big changes that happened
(the 13.0). Make the usability better in order to avoid potential
multi-company issues for the user.
Specification
Check the related commits to see the different fixes that have been
made. For more information about the technical/functional considerations,
check the related task.
Taskid: 2088891
X-original-commit: 5c8df3a5e5f7960e5eab6439e0a32a06224ba826
This commit provides hard constraints (SQL level) for expense to work in multi company
environement. This is related to a R&D task, the rest of the code need to be adapt, but
freeze is coming.
As expense implies accounting entries, it is required to generate them in the right
company, the company field should then be required.
Task-1999686
closesodoo/odoo#35953
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
Purpose
=======
Access group terminology is missleading. Yous have to be manager to administrate
an application. This task consists to rename groups to be understandable for everyone.
Groups should be reorganised on the users form to be more explicit.
Specification
=============
1/ Rename 'Manager' to 'Administrator' in users groups.
2/ Define a hierarchy on access groups by using the category_id in the manifests
A category 'Operations/Project' will create a category Project with a parent
category 'Operations', and something smart is already developed (in modules/db.py)
to avoid duplicating categories.
3/ Add a group in expenses to be able to approve expenses reports for my team.
4/ Add a group in timesheets to be able to approve timesheets for my team.
5/ Remove partially the useless crap in ir_module_category_data.xml
6/ Sort access rights groups on users form according to its parent category
closesodoo/odoo#29362
Signed-off-by: "Yannick Tivisse (yti)" <yti@odoo.com>
Currently the distinction between expense officers and expense managers
doesn't make sense because they both have the same rights.
This commit aims at making a clear difference between an officer and a
manager.
After this commit the rights will look like this :
* Expense Manager :
- See and approve any expense
* Expense Officer :
- Can see and approve the expenses of employees in his department
or employees for which he is the manager (field parent_id on
hr_employee)
- Cannot approve his own expenses
* Simple user :
- Can only see his own expenses
- Can only send his expenses to a manager (either the manager of
his department, his direct manager [parent_id field] or an
expense manager)
Related to task #51520Closes#23033
A product can be sell or expense, but for some cases the product
configuration make both flow incompatible. Indeed, when expensing
the delivered qty was computed based on the AAL total amount, and
manually editable.
Before the delivered qty refactoring, reexpensing erased the manual
value.
This came from the fact product expense policy is wrongly used: the
delivered qty of expensable product is not manually editable, which
is a problem for milestones (and other consumable product when stock is
no installed).
The new refactoring of deli qty API force the expense line to be
completely
readonly, but the problem is not completely solved; we still can't sell
properly a expensable product.
To do so, the SO line must be flag as coming from an expense or vendor
bill, and the reinvoice product policy should only be used to calculate
the price of new SO line.
This commit:
1) reinforces the readonly caracter of expense SO line, by making the
expense policy independent of the computation method for delivered qty
on SOL.
2) prevents generate picking when updating ordered quantity on a expense
SOL with a stockable product.
3) allows service to sell a task with zero hours as ordered quantity.
(it still prevents task/project creation for expense SOL).
4) does not increment anymore an existing line when expensing product
at sales price and invoicing at 'delivered qty'. The only line to be
incremented will be the expense line (and not the native SOL).
This commit make expense test depending on the
same common class as the other (in sale_expense).
Some data were badly defined (test data), using
field only existing when sale is installed. So move
this part in sale_expense.
Expense tests now check analytic entries when
sumbitting an expense.
Accounting tests are executed post install to be sure a chart
of account is install. However, for some case, we might want
to run test at module installation, involving accounting, without
being sure a chart of account is installed.
This commit provides a base common test class with a minimal chart
of account (some journals and accounts) allowing to start tests at
installation. this class should be extended in sale or expense for
this modules to be tests at installation. We will required this for
reinvoice test in sale later (test consumable product when sale_stock
is not installed, but maybe without a chart of account). The idea is
each test suite can call method to setup their own data.
This commit also use this common test class in sale_expense.
Thibault Delavallée