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
All portal features were moved into base
and website_portal, portal module is obsolete.
This commit remove its code, and modify the modules
dependencies accordingly. website_portal now depends
on auth_signup.
The goal is to prepare the removal of
'portal' module.
- demo portal user is moved into base
- 'is_portal' field on res.group too
- remaining security rule are moved to base too
- mail template is moved to website_portal
now based on the new implementation of payment.
[REM] portal: removed acquirer model, views and implementation
[REF] portal_sale: now using payment rendering methods
[IMP] payment: added render_payment_block, taken from old
acquirer, that renders all portal_published acquirers.
bzr revid: tde@openerp.com-20140122190022-lef4b3o1tpcua3vx
portal.payment.acquirer stores payment processor
options (formally called payment acquirers). Each
acquirer is just a name and an HTML form template,
used to render an HTML snippet that can be included
in views where a payment option should be displayed.
The aquirer model has a generic method for rendering
a complete block of HTML to be included in form views
directly (with matching CSS): render_payment_block().
This method takes a few parameters to figure out
the name/reference, amount, currency, etc. to pay.
bzr revid: odo@openerp.com-20121024131554-j01ucniecjmoz3jq
right now, only 'public' and 'private' are working; 'portal' will
require some tricky ir.rules and probably a group dedicated to
anonymous users
bzr revid: abo@openerp.com-20120703165306-27erhp9vj3rdg7o2
Martin Trigaux