| Age | Commit message (Collapse) | Author |
|---|
|
The modification of countries data should be restricted to knowledgeable users.
Indeed, by modifying, deleting and/or creating res.country records, the resulting
behavior generally won't be what you expect, breaking existing flows (delivery, taxes, VAT validation, ...)
in an open OR hidden way...
By restricting those modifications, we reduce the risks of users breaking their database through
'minor' changes unexpectingly triggering 'heavy' problems.
|
|
The document layout preview is a complete defferent simplified template
with its own css that replicates at best the different styles.
It does not have the external layout features and lack of fidelity.
The new preview actually use the real documents templates and put the
result in an iframe. It now has a high fidelity, though not perfect.
The goal is for a better onboarding, where clients see easely how
documents will look if they had an app to generate them. Of course, the
data on the document is a false invoice.
Refactor all this from base to web.
Task ID 2304177
closes odoo/odoo#56415
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
|
|
Custom actions may contain sensitive information, including business
logic
Task-id: 8203
|
|
* ability for a user to request / create keys associated to their user
* overrides can block RPC solely through API keys, by overriding
`_rpc_api_keys_only()` (to require API auth even in
situations where the user has not requested it themselves)
* hash keys just in case as we can do so and might as well, add a
cleartext index (first 4 bytes of 20) to avoid blowing up the DB if
a user decides to create millions of keys for some daft reason
* users can delete their own keys, admins can delete (invalidate)
anyone's keys
* `scope` on API keys can be used to restrict usage to certain
kind of applications, so API keys can be used for other things
than global authentication. New keys manually created by users
have no scope by default so they are valid everywhere (global
keys). RPC auth (stateless XML-RPC/JSON-RPC) requires global keys
Co-authored-by: Florimond Husquinet <fhu@odoo.com>
Co-authored-by: Olivier Dony <odo@odoo.com>
|
|
Similar to github's sudo mode, my understanding of the intent is to
avoid third parties being able to perform sensitive / serious
operations when leaving a logged-in machine unattended.
This v1 only handles protecting "action methods" (methods called
through buttons and intended to return action descriptors), although
they can be used to "lock out" any methods they won't be able to
prompt and the caller will likely be surprised.
|
|
Before this commit only admin setting user can merge contact which is a bit to restrictive
Contract Creation group seems more adequate
closes odoo/odoo#54831
X-original-commit: b5d5bc30dd3769deab09cbc0915741a93df229ef
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
ACLs on the wizard lines should match that of the wizard, otherwise
ERP managers can see the action but get an error as soon as they open
the wizard.
Since ERP managers have write access on arbitrary users, that's
probably the right group to use.
Task 2275134
closes odoo/odoo#53007
X-original-commit: 657d44f08c402bc0547b7cbb01c2d447e641d062
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
|
|
Only administrators can access properties and configure them.
ir.property may contain sensitive information and should only be
accessed via code call to specific methods
|
|
Only system users should be able to access directly ir.ui.view records
Other users should use helper methods like fields_view_get or render
to interact with view records (or use sudo)
Give read access to views to publisher
He needs to call read_template on some views like
'web_editor.colorpicker' in edition mode
Restrict ACL on website.page
Apply the same ACL than on ir.ui.view as the model inherits from it.
Give access to designer to modify views
|
|
Add a new group allowing administrators to remove the ability for
users to bulk-export data from the database. It's pretty minor as
technically the user can still access the underlying object through
the basic methods but it's still a bit of a roadblock.
Users can export by default.
Task 2170900
closes odoo/odoo#45400
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
|
|
This commit adds the possibility to compare a view arch to another one.
The result will be shown in a diff viewer (github like).
This is following what was done at #32009
task-2190072
closes odoo/odoo#44646
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
|
|
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
|
|
The selection values of a selection field are now stored in database in the
model ir.model.fields.selection
This will allow to have a modular approche on selections and each selection
is now linked to the module that declared it.
Previously to this change, the selections were linked to the field, meaning
uninstalling a module had no impact on the selections stored on database.
With this change, the selections will now be translated in the correct module
(having an external id) and the records having a used selection will now be
reset to null.
closes odoo/odoo#30228
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Co-authored-by: Raphaël Collet <rco@odoo.com>
|
|
The onboarding modal for setting up the few base fields of a company
has now been moved to a wizard
It is accessible from the general settings, but also in the onboarding
section of sale and account modules.
The following company settings are editable with that wizard:
- Set report **layout**:
The user can chose the overall look of the report. The current choices
are : *Standard* (default), *Background*, *Boxed* and *Clean*.
- Set company **logo**:
Changes the company logo.
- Set report **colors**:
The user can set the primary and secondary colors of the report through
a newly added widget allowing to pick a custom color.
When changing the **logo**, colors are automatically set to its most dominant
colors.
> A "Reset colors" button also triggers the color calculation.
- Set report **font**:
Changes the overall font of the report. Only Google Fonts are used
for enhanced compatibility.
- Company **tagline**, also called "header"
- **Footer**
- **Paper format**
- Report **preview**:
A mockup of a final report
Automatically updates when changing **layout**, **logo**, **colors** or **font**
Co-authored by: Julien Mougenot <jum@odoo.com>
closes odoo/odoo#33863
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
|
|
It should not be a standard model but a test model
|
|
There is no reason to interact directly with it.
The method precision_get is done in SQL and ormcached, it is better to use it
|
|
The decimal precision feature makes sense to be an ORM feature, no need to be
in a specific module
Previous syntax was
from odoo.addons import decimal_precision as dp
fields.Float(digits=dp.get_precision('Foo'))
and now is:
fields.Float(digits='Foo')
Remove the possibility to have a callable method on the digits attribute (it
was only used for precision anyway) and directly retrieve the digits on the
decimal.precision model
Rename the method digits to get_digits to avoid confusion between the field
attribute when declaring a field and the method to retrieve the precision
Task id: 48198
|
|
Now that portal users don't have access to the backend, it doesn't make
sense to give the read access on attachments, as this is the role of
the specific controllers to provide this access according to the business
logic.
For the record, these rules have been introduced at:
https://github.com/odoo/odoo/commit/61065b6d04248aa496765e1035c4c90cbdc38de7
https://github.com/odoo/odoo/commit/f3fa266d115ac9d4723164af10f8dee40821b290
closes odoo/odoo#32134
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
Was called "group user" while was applying to manager
Fixes odoo/odoo#31300
closes odoo/odoo#31537
|
|
|
|
If a user creates a paperformat, he should be able to modify it too.
Employees have no reason to modify the paperformat though (nor create).
Having a malicious employee modifying an existing report may be dangerous.
[CLA] signature for stijnh92
Fixes #26292
closes odoo/odoo#27444
|
|
Not used since a while, remaining of old res.request. Requests have been
removed at 881a76dbcf47c877feb5efa14943010309d22eaf . Links have been kept because still
used in some reference fields. It seems the last use was in OpenERP v9.0
in crm_claim module. As links are not used since a while let us get rid of
it.
|
|
|
|
|
|
|
|
purpose
=======
We need to store and produce reports about customer activity sectors to improve references mechanism.
Specification
=============
- add a new model res.partner.industry "Sector of Activity"
- fields:
- name (translatable)
- full_name (translatable)
- active
- add minimalist form and list views (à la Contact Tags)
- menu: Sales/Settings/Contacts/Contact Industries (Technical Settings only)
- ACL: R for group_user, CRUD for group_system
- add a default XML data file to preload res.partner.industry with the ISIC 2008 aka NACE rev.2 level 1: https://docs.google.com/a/odoo.com/spreadsheets/d/1IrGbHIaaDDkBAS2uGABeNRPndtYbyVBVoYYpQNXnhnY/edit?usp=sharing
- Note: we leave it as an option for end-users to import their own industries, because there are many competing standards: ISIC, NACE, NAICS, OKVED, etc.
- Each standard also has different hierarchical levels, and we only use the top level one by default.
- add a m2o industry_id ("Sector of Activity") on res.partner towards res.partner.industry
- add industry_id in partner form view, in Sales & Purchase > Misc, only visible when contact type is Company
- No quick create for this field
|
|
The content of the report module is now dispatched in
the 'base' and the 'web' modules.
|
|
- RML Reports
- Webkit Reports (most part already removed by 13b9982c6298021289707ed364e3c1d622a09f13)
- LocalService in netsvc.py
- rename attributes like rml_% to report_%
- rename ir.actions.report.xml to ir.actions.report
- allow rendering directly on an ir.actions.report by calling render method
- remove 'controller' report_type
- remove unused res.font stuff
- remove print_report method in models.py (not used)
- restore removed call to pdftotext process in test_reports
|
|
|
|
About a `sudo` on ir.ui.menu, this commit (3649b7f359b640635cbe0bc4f161884ba64c2318) removed it,
this commit (3d0cc2d6d2dbd567cfaa93de4cb90787d0c07c9e) re-added it.
Since portal user can not go on /web anymore, I think portal does not need to read ir.ui.menu.
Here some news scenario:
- if website is not installed, portal can log in, but will be redirected to login page
with an error message 'only employee can access'. Indeed, there is no page to display for
such user.
- if website is installed, but not website_portal, portal user can log in and will be
redirected to homepage. If he tries to manually access to /web, he will be redirect to
login page with access error (even if he will still be logged).
- if website_portal is installed, the portal user can fully enjoy its features.
|
|
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
|
|
employees
|
|
This partially reverts commits 5d746d0ac663232d656bb57e82fec290bb5d82fd and
73de86c7682a1433da7a755c3092dcb38fba3fd8.
The tightening of access rights was too strong: regular users need to be able
to read models and fields (to create an email templace, for instance.)
[FIX] ir_values: in `get_actions`, exclude field `code`
|
|
The computed field `domain` was formerly read as the current user to evaluate
the rule's domain for the current user. As we restrict the access of `ir.rule`
to advanced users only, the computed field has no purpose anymore.
|
|
|
|
In `website_crm_partner_assign`, remove duplicate ACLs and reorganize files.
|
|
|
|
|
|
|
|
Remove unrestricted "read" access. To make code internally using `ir.model`
work, add a private method `_get` on `ir.model` to retrieve the record
corresponding to a model name, without access rights issue.
Change signature of method `get_authorized_fields` to make it use a model name
instead of a model id. This removes the necessity of a search on `ir.model`.
|
|
Remove "full access" for all users, and add it to specific groups.
|
|
Add `sudo()` to call `get_param` where necessary, and make the web client use a
controller instead of directly accessing parameters.
|
|
ir.needaction_mixin is not used anymore by the webclient.
From 9.0, the concept has changed: this feature is now
available in mail module, with the mail.thread mixin,
and message_neeadction field.
Remove all code handeling needaction bullet and
counter on ir.ui.menu, knowing that since 9.0
webclient does not display the counter anymore.
This code was, thus, useless and some RPC calls
were done for nothing, and adapt accounting
reconcialiation widget.
|
|
|
|
|
