Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Avatar

Re: [PSA] mail template editor group, mass mailing user group

by "Graeme Gellatly" <graeme@moahub.nz> - 29/02/2024 20:09:43
Interesting. In a v16 enterprise migration it does not give that permission.

This meant that the built in followup letters could not be edited. It is fairly easy to work around as the ability to edit a rendered message is not determined by group but by computed field. The biggest issues with giving users access to template editing is not security by the way, it is the fact they will cock it up as you need to understand object notation, translation management and that you are affecting everyone.

We have written a lot of security changes/enhancements as I'm sure many others have. A lot have been to mitigate unforeseen multicompany effects but not all. Off the top of my head these are some of the things we could give fairly immediately although like most internal code, it will need some generalizing/refactoring..

Master Data Security - basically stops regular users doing crud on warehouses, products, uom's, locations except for a very few whitelisted fields.
Partner Lock - Allows to lock a partner so it cannot be changed unless unlocked (e.g. a key supplier where clowns change the email address, or a company partner record)
The stuff for mail templates.
Sane Accounting Access defaults - this actually adds functionality to Billing User so they don't have to be given Accounting Access to do things like view Payable/Receivable Report or reconciliation screen.
Adding an intracompany user (different to inter) locked to a single company rather than using uid 1 or OdooBot.

I think maybe access management is a better term than security for this, as we are really only talking about User Access.

On Fri, Mar 1, 2024 at 7:32 AM Holger Brunn <notifications@odoo-community.org> wrote:
> I think a security repository sounds like a great idea. I am less


> enthusiastic about auto-installation, as its use is a bit contentious and


> has spawned modules like  module_change_auto_install [1] .

but exactly that repository would be for people who want an installation that 
is, well, for however we define it 'secure by default'. There I'd find it a 
feature that if you have the repo, and install some module from core that does 
things violating our idea of 'secure by default', you get the module that 
squelches that violation immediately.

If we don't have the auto install, every integrator will have to depend on 
those modules explicitly, which I will do anyways for my customers, so for me 
it doesn't really matter. Still I think it will be more convenient for most 
people to just pull this repo into however they do their deployment, and then 
the magic happens.

But I agree, much less modules than authors think are a good idea to auto 
install in the general case.



-- 
Your partner for the hard Odoo problems
https://hunki-enterprises.com

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

Reference