I'm trying to set up a custom content type in Bolt so that only the owner can edit their own record. i.e. to stop users editing each other's records.
I don't seem to be able to get the right combination of permissions in permissions.yml though.
Using:
contenttypes:
mycustomcontenttypes:
edit: [ owner ]
in the content-type-specific permissions lists all of the mycustomcontenttypes on the overview page when I'm logged in as an account that owns a subset of the records, but none of the records I own have the title wrapped in a link leading to the edit page and the "Actions" menu does not have the "edit" option.
I would have expected the "owner" role to exist in order to give owners permissions relating only to their own records - surely that's the point of that role?
Is it therefore possible to set my custom content type such that (outside of superusers like root, admin etc) only the owner can edit their content record?
Related
I want to allow user to update data from form, but not from direct table. I added Before Change event on table, and raising error if the user group is 'basic'. This is working as expected if I enter data in table. But, it is also raising error even if saving data from form. Can anyone help me to resolve this issue?
Thanks in advance!
In general the way to deal with permissions in Access is to only ever show your users the forms; they should never directly interact with a table or query. So instead of adding Before Change code to your table, you instead want to hide the table.
The things you need are in the Current Database section of the Access options. For this example I'll assume you just have the one form, but the same applies if you have many forms and a "Home" form.
Use the "Display Form" dropdown to select the form you want the user to see when they open the application.
Un-check "Use Access Special Keys" to prevent keyboard shortcuts showing objects you don't want shown.
Un-check "Display Navigation Pane" to hide the object list.
Un-check "Allow Full Menus" to prevent users from creating new objects (or use other database development functions)
With this done, the user will see only the form interface you selected and the basic data entry toolbar.
Note that when you want to make changes to the file as a developer you must hold down Shift when opening the application, which will display the navigation pane etc. Of course, any user who knows about the Shift override could do the same. Which is why distributing in a compiled accde, which cannot be unlocked, is a good idea. But you need to set up the application using the above options before that matters.
hi i am working on SSRS report and all my reports are deployed in server with all the user permission but not sure why permission is not working sometimes when new user is providing permission.
as per my knowledge i know that i can set permission with 3 different ways.
1. Site level
2. folder Level
3. Report Level
when ever a new user need permisson to view the report, i follows the below.
Step: 1 opened the Reportmanager URL(http://toshiba-pc/MyReports) and click Home
Step : 2 clicking on "Folder Settings"
Step 3: Click on "New Role Assignment" and enter the domainname\TestUser with "Browser" role and click ok and TestUser user is automatically adding into all the folder
problem : some of user is not appearing into all folders some of the user is appearing into all folders.
to avoid above problem, i added DomainName\TestUser into folder security and it's again not appearing for all reports security , so again i have to add this user into the reports where use has not added.
this is very difficult to go each report to check whether reports has permission or not?
is there anything i am missing to configure , please let me know.
do i need to set role(system user, system administrator) for all the users to site setting. i never add user into site setting..
Please any one let me know what i am missing to configure.
Thanks
By default all permissions cascade to every item contained within the folder. This means that providing someone Browser access on the Home folder will give them Browser access to everything on the site.
This inheritance stops if at any point you have individually changed the security context of any item in the Report Manager. If you have ever done this, you will see the option to Revert to Parent Security when looking at that item's security settings:
Clicking this will remove the custom security context on that item and reset it to match the security context of the containing folder.
To find all items that have a security context different to that of your home directory so you can change them in the Report Manager (You can change this in the ReportServer database, but you run the risk of breaking your entire reporting catalogue and Microsoft will offer you no support for editing the database directly) run this query on the server which holds your ReportServer database:
select *
from ReportServer.dbo.Catalog
where PolicyID not in(select PolicyID
from ReportServer.dbo.Catalog
where Path = '' -- Home Path
and Name = '' -- Home Folder
)
With the admin user I can do everything, add, delete, modify, etc. As it should be.
Then using this user added a new one, with full access to sales and accounting options as some other ones needed for sales operations. Then tried to add a new supplier and it throws a warning:
Access Denied
The requested operation cannot be completed due to security restrictions.
Please contact your system administrator.
(Document type: Pricelist, Operation: read)
Tested all the possible combinations on user rights and ended up giving full access to all options. Nevertheless I'm unable to create any new contact/customer/supplier/etc with this user. I'm running out of options, I don't know what else to test or where to look.
EDIT
Got an answer on the brand new OpenERP discussion site recommending to uncheck the Portal user rights for the user. Uncheking it partially worked. The warning still appears but when I click OK, fill the supplier and save, the new supplier is added without errors. Any recommendation?
I really think that's not a bug.
it's a conflict of "Rights" (in Access rules and ACL).
A "Portal or Anonymous" user, is an external user (from the company) and have only some limited rights for accessing some public informations or it can be an exteranl partner which can access his private documents and informations related to his relation with this company.
A normal OpenERP user (a company employee with some or all rights "let's call it an internal user") can't be and should not be in the same time a "Portal or Anonymous" user (with very limited rights), and vice-versa.
Just uncheck these two options for an internal OpenERP user.
Is a reported bug that seems to be related to multi-company option selection and user rights.
Go to multi company Access Denied Document type: Partner, Operation: read where the bug was reported and is followed up by other users. Hope a patch is created soon.
I agree, I don't think that's a bug.
I got that error with a user when I created an employee linked to this user.
You have to be at least an employee from the society to add a new client.
Link to create a new employee :
http://yoururl:PORT/?ts=1369948181483#view_type=kanban&model=hr.employee&menu_id=273&action=328
I got the error when I granted Portal rights to a contact/customer, then when a Quotation is sent (testing), opeing the Quotation yields the error message:
Access Denied
The requested operation cannot be completed due to security
restrictions. Please contact your system administrator.
(Document type: Partner, Operation: read)
However, clicking OK, can get past it and proceed to pay. This is a major ongoing sort of issue with OPENERP. It should be fixed by now...
I just faced a similar problem, may solution was to add a record rule for the Administration / Settings group, here is how:
1- Go to Settings->Groups and select Administration / Settings. (Make sure this group is assigned to de new user)
2- Click the Edit button and go to the Rules tab. (It should be empty)
3- Click the Add button, this action open a modal window, click the Create button on it.
4- Give the new rule a semantic name - e.g. Partner: administration settings: see all - and make sure all the access rights are selected.
5- In the object drop down type res.partner, it will allow you to select the object named Partner referenced in the error.
6- Click the Add button in the Groups section and select the Administration / Settings group.
7- Finally click the Save & Close button and save the group changes by clicking the Save button.
Hope this is helpful for beginners in OpenERP. Actually I already have used this solution patter more than once for similar error related to permissions a given user was expected to have.
Its a rules issue. Deactivate the rule Product Template . Rules overrule access writes setup under the user setup. So it looks like users have identical access but these rules bypass your customisations.
i think you should active developer mode, and go to setting/user -> select the user have this error. Then click edit and uncheck public in "Other Extra Rights" section. After that, click save.
TYPO3's extension be_acl helps to manage permissions on pages on complex installations, when multiple groups works together.
Just there is some kind of bug : when a user creates a page, permissions of page-parent are not inherited, and we should resolve the conflict manually.
Ex. :
page parent number 1 is assigned to two user groups A and B
a user from A group creates a subpage 2 under 1
a user from B group couldn't edit page 2, as the permissions from page 1 were not inherited, and default permissions for others is only "read"
Such conflicts provokes bugs for further BE user's collaboration, the admin should resolve conflicts manually.
Does anybody had such type of permissions conflicts and managed to resolve such issue ?
#cascaval answer in question's comments helped to manage the issue.
Key elements :
Latest version of be_acl
Recursive option is filled in be_acl record
All groups are defined in be_acl style, and not in traditional TYPO3 maner, to realize heritage on sub-pages
I understand how to restrict entire pages, or even components by implementing <cflogin> and roles. For example:
<cfif IsUserInRole("Admin") OR IsUserInRole("Accounting")>
...You can view this page...
<cfelse>
...You can not view this page...
</cfif>
But how is it recommended to restrict certain facets of a page? Say for example an "Admin" is allowed to send Global Messages to all users, but that option is not available for a regular "User"
I suppose I could use the Session to manipulate my Views (pages). How is this typically handled?
You're right, securing a page and securing elements is different.
In my opinion and in practice, I think tying any code to a role or user is actually the wrong approach. Instead, tie permissions to elements and pages - then tie roles to those permissions. And of course, users are assigned roles.
It is important to have all three :
Users
Roles
Permissions <-- this is what you're missing
Permissions are what secure elements and pages, not roles or users Your code should have no clue (because it doesn't need to) what users or roles there are - just names of permissions.
When a user logs in, I grab their role(s). Then I grab all the permissions that are assigned to those roles (simply a list of string values).
For example, on a page I might have :
Add item
View item
Delete item
When I code that page, I actually secure each of those elements with permission strings named similar ( addItem, viewItem, deleteItem).
<cfif listContainsNoCase( session.permissions, 'addItem' )>
<!--- code to add item --->
</cfif>
(Note: I recommend using a custom tag or function for this, but for purposes of an example, the above works fine).
If you do it this way, it provides maximum flexibility and abstraction. If you secure elements based off of roles, you limit yourself :
Adding new roles will require a lot of code changes!
Changing permissions between roles requires a lot of code changes!
If you do it as mentioned above, you will never need to change your security code within the code base, because "addItem" permission should always be on the "add item" logic, right? :)
Now if you happen to need to create a "manager" type role, that has all the user roles and a select few admin rights, you simply create that role, and assign it the correct permissions (maybe addItem and editItem, but not deleteItem). Bam! Now I have a manager role to assign to users with no code changes!
If I had sprinkled my code with "is user this role" type of stuff - I would have to go edit my code everywhere to allow my new role "manager" - yuck!
Make sense?
=)
Things start going awry when businesses like to change the permissions that a Role has often because they don't know how else to give someone rights to do something.
So lets say a user in Marketing wants "update" rights to do some task. Someone in the business gives them the Update permission. But an IT Manager also has "update" rights which gives him access to things that the Update permission for Marketing should not.
So... I actually go one step further and specify Roles that have Permissions based on what Department that user is in. Yes its very complex and very tedious to manage hence I ended up on this question in my search for a better way to do it.