| Age | Commit message (Collapse) | Author |
|---|
|
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
closes odoo/odoo#29362
Signed-off-by: "Yannick Tivisse (yti)" <yti@odoo.com>
|
|
|
|
This reverts commit 382fbd35204ff947c16b795ca090c97d6741fb1d.
|
|
User 1 simply becomes a technical user (inactive, no password).
|
|
When splitting purchase and stock, the access
rules of the report was wrongly moved to
purchase_stock. This commit restores balance
in the universe.
|
|
We want to break the dependency between stock and purchase
for our furtur developpement. For more modularity, a new
bridge module 'purchase_stock' is created.
This commti move part of business code, views, data, ...
related to stock management from purchase into purchase_stock
without changing any feature.
Task #47927
|
|
The categories other extra rigths and hidden are not used now.
|
|
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
|
|
* analytic accounts can be shared among companies
* amount on analytic lines always refer to amount in company currency of which it belongs to
* add analytic groups (hierarchical way to classify analytic accounts)
* analytic tags:
- only present on analytic lines, not anymore on analytic accounts
- can be used to distribue/split an analytic lines among several analytic accounts
- enabled by a dedicated res.group
- added on several objects (vouchers, expenses, analytic defaults...) as well as in bank statement reconciliation widget (manual counterpart and account.reconcile.model)
* bunch of fixes made related to analytic
Was PR #22124. Was task 32386. Original work by tbe.
|
|
|
|
|
|
Apply an inter-company rule for the purchase.report
opw:779192
|
|
|
|
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
|
|
|
|
And add a category hidden on the res.group definition
|
|
Improved usability & code cleaning:
- Support for blanket orders, in addition of purchase tenders
("Purchase Agreements")
- Create a RfQ in one click, no wizard anymore
- Control of quantities really purchased
- Better control of side-effects thanks to purchase requisition types
- JS code removed (not necessary)
- Workflow removed
Closes #11666
|
|
|
|
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.
|
|
menuitem
|
|
group as well as option in res_config for advance mode
bzr revid: csn@openerp.com-20130529154305-zhok6su2fmlet3x9
|
|
Alexis de Lattre (Akretion)
ir.rule records are in noupdate data blocks to let the admin
alter them without fear of them being reset at next update.
Other records such as groups are in normal mode, so they
can be updated whenever necessary
bzr revid: odo@openerp.com-20121218232001-t425t4hi7qbmsip2
|
|
bzr revid: cha@tinyerp.com-20121122125417-yo3ma88is5euw038
|
|
bzr revid: fp@openerp.com-20120916150517-16vr5lp419b0kpid
|
|
- ir.rule objects are noupdate="1"
- all other objects are noupdate="0"
bzr revid: alexis@via.ecp.fr-20120713170838-pjsysliyt6twazrc
|
|
menutip
bzr revid: mma@tinyerp.com-20120517054451-o3g0c8b62ug4k19m
|
|
inclusion explicit in groups
bzr revid: rco@openerp.com-20120404090830-nteimn2kvz8nkk7h
|
|
analytic accounting group
bzr revid: rco@openerp.com-20120402094204-09h0upptc7qric7a
|
|
bzr revid: rco@openerp.com-20120330120730-dilz5owc82s3yrl0
|
|
respecive module
bzr revid: rco@openerp.com-20120329142121-lc5b6d3mcds68p34
|
|
bzr revid: rco@openerp.com-20120322110834-k49v2g4w1wd9jqk2
|
|
bzr revid: tpa@tinyerp.com-20120307115453-he70yxpcpxsr1yfx
|
|
bzr revid: rco@openerp.com-20111212140528-g8oxverkipswionf
|
|
bzr revid: rco@openerp.com-20110802130811-pkdmw43ufifz0tpj
|
|
By default only records belonging to the user's company or descendant companies
should be visible. The original patch introduced visibility of records
from ancestor companies, which should be suited only for a few cases, such
as res.patner.
Original revision: 3164.24.175 sbh@tinyerp.com-20101223095216-n6psmzicdcs8is8x
lp bug: https://launchpad.net/bugs/720175 fixed
bzr revid: odo@openerp.com-20110228135754-6skiy4fb9dg54xb6
|
|
bzr revid: sbh@tinyerp.com-20101223095216-n6psmzicdcs8is8x
|
|
bzr revid: rpa@tinyerp.com-20101119102525-8gyj1gmm1w29rwxu
|
|
Task id: 1771
bzr revid: aag@tinyerp.co.in-20101111131855-v07piwfyp33wlmng
|
|
bzr revid: fp@tinyerp.com-20100629120926-9c7qdw0mug279ehh
|
|
bzr revid: rvo@tinyerp.co.in-20100428125109-wq33afl8104gx6rf
|
|
bzr revid: mga@mga-20100316143337-ng6bmx315jq3ymu4
|
|
bzr revid: fp@tinyerp.com-20091128092522-g7fumj3p55kv6ygr
|
|
bzr revid: stephane@tinyerp.com-20080910175600-tutctqg606c9eil4
|
|
bzr revid: fp@tinyerp.com-20080903182533-bi4u27xqnm2mmhhr
|
|
bzr revid: fp@tinyerp.com-20080903180400-df7l6wxg1zpirmmi
|
