I have an object which is controld by its parent (it has a Master-Detail relation).
The parents OWD is set to private.
My problem is that the user can add a parent record but when he adds a chield he gets this error message - "Insufficient Privileges - You do not have the level of access necessary to perform the operation you requested. Please contact the owner of the record or your administrator if access is necessary"
Does your user have the "Create" right to the Child object?
The issue here may be the attributes of the master detail field on the child object.
For example, if your OWD Access to the master object is set as Read only then the master detail field on the child must also be set as read only.
You can do this by editing the field - In the Master Detail options section of the field edit page edit the "Select the minimum access level required on the Master record to create, edit, or delete related Detail records" setting.
Hope this helps.
Related
Is it possible to validate the Xpage's ACL depending on the Source document's field value.
We need to make the Authors & Readers ability at XPage level (as per requirement I am not supposed to use the ROLES, since, it is dependent on each individual Authors which is stored in backend document FIELD).
Kindly suggest the approach, as I am not even looking HideWhen for the Buttons(edit,save etc)
Example code in the ACLEntry[0] in Xpage:
if getComponent("inputText1").getValue() == sessionScope.user {
session.getEffectiveUserName();
} else {
return false;
}
Thanks.
I do not quite understand your code on that property...
To query the readers/authors level at XPage level I suggest to use the database.queryAccess method (http://www-10.lotus.com/ldd/ddwiki.nsf/dx/NotesDatabase_sample_JavaScript_code_for_XPages?opendocument&comments#queryAccess)
You try to compare the username only. This may fail if your access level is computed by a membership in a group where your username is not relevant.
XPages' ACL depends on the database ACL, so you have to setup the levels there - the XPages' ACL is in addition to the "real" ACL as far as I experienced.
I also experienced that readers fields affect the ability to use an XPage to open a document by default.
I hope my answer is not too confusing ;-)
I think the question is valid (to my current knowledge):
If I want to design a workflow application but the current approver should not edit the full document I want to give him only access to parts (ie. a comment field and the approval button).
The question above relateds somehow to access controlled sections in old LN development. I so far also didn't find a good solution
What you describe is a very common workflow scenario. There are several ways how you can implement that efficiently. Here is what I would do:
Have one (or more) custom controls that render the "payload" (the fields the requester fills in)
assemble them into one bigger control that is used to render the form
compute the mode to read/edit depending on who is opening the form and the mode (new, pending approval, approved, rejected etc.)
Optional: when submitted remove submitter from the author field
Have one "Approval Control" that show only when the current user is the (current) approver and status is "pending approval" That control has fields that are NOT bound to the document, but a scope variable
The approval button triggers SSJS that takes the scope variable values and updates the document (and triggers notifications, access change etc)
The approval component can be used for any approval form. You then can contemplate not to give the approver write access since you could handle that in code.
What I need
I have a custom Entity with that with multiple fields. Admin Role has "god" access. All other roles except for one have read only. The one non admin role with update access, should only be able to update a single field.
What I believe to be true
I believe I have three main options to implement this requirement:
Enable Update Access to the role for that entity then write Javascript to disable all fields on the form for that role, except for the one that I want that role to be able to edit
Enable Update Access to the role for that entity then create a new form that disables all fields on the form for that role, except for the one that I want that role to be able to edit.
Enable Update Access to the role for that entity then turn on field security for each field, disabling access using the field security, for each field except for the one I want them to edit.
What's the Best Practice?
What options should I choose?
If I go with options 1 or 2, will the user be able to edit the field on the bulk edit form?
From a user perspective, I think it's confusing when a form opens up with things enabled, then they get locked down. Plus someone could possibly get data in there before the fields get locked. I'd say you'd have to combine this with a plugin to prevent changing fields you don't want changed.
I like this option better, although again, the field can be unlocked if someone knows what they're doing, so a plugin to double check would be nice.
This would avoid having to double check in a plugin, but you also have to rely on the admin correctly setting up security for new fields going forward. If that's not a concern, this might be best.
Bulk edit is a global privilege, so they'd have bulk edit for all entities. Also, the bulk edit form does not load scripts, so that knocks out option 1. I'd say if it's just this one field, I might leave the privilege locked down and provide my own Bulk edit button on the grid that would show a custom page that just has that one field on it, then handle the updates though script.
2 is most likely best, or as an alternative put the fields in the header or footer rather than as read-only fields on the form.
This also means the fields won't be available to bulk edit, but other methods such as data import or workflows would let users get round this if they know how and have rights to do such things.
3 Field Security is the most robust and works for all scenarios
Possible option 4: create another entity to contain those fields and apply different security to that entity. If created as a child, show the record in a grid on the form with the values included in the view. If it is a parent then you could use methods such as showing the values via an HTML webresource page included on the form.
Consider user is denied access to a table of financial secrets:
SELECT * FROM Transactions
SELECT permission denied on object 'Transactions'
No problem:
CREATE VIEW dbo.Transactions2 AS SELECT * FROM Transactions
Command(s) completed succesfully.
SELECT * FROM Transactions2
(84,387,982 row(s) affected)
Are users supposed to be able to bypass deny permissions on a table by aliasing the table?
Edit: Sauce:
This is working as advertised
It's called "ownership chaining"
dbo owns both table and view/function/stored proc
view/function/stored proc references table
table permissions are not checked at all (for GRANT, DENY, whatever)
If you don't want someone to see a column/table, don't have it in the view/function/stored proc. Or add logic/joins to check permissions according to whatever model you've used.
Previous answers: one, two
It's been in SQL Server and Sybase since, well, long time.
Isn't this part of the intent of views in the first place? To enable visibility to certain, specific information from tables when the user does not otherwise have select permissions on the underlying table(s)?
Sounds like the problem here is that the user in question has rights to create a view in the first place.
For example, say you wanted to expose the non-confidential information in that table; you could do that with a view that limits the results only to what you wanted to be seen.
My requirement is that there are 2 parties
1. User (who creates the item)
2.Approvers who approve the item
When the user creates the item then they should see only their created item in the list (This is easily possible)...the approvers should have only read access and they can see all the items ...when i select the option that only person who creates the item can see the item then approvers are not able to see the items...can somebody plz help that how to work with this...maybe i am missing some simple stuff so can anybody just point me out to the solution..
Thanks
Firstly, if you want the Approvers group to be able to approve the item then they need at least the Approver permission assigned to their group, not just read-only (otherwise they can't update the item to mark it as approved).
However, since the requirement is also that users should only see their own items, I believe the only way the Approvers will also still see the items, is if they have Full Control permissions on the list, therefore you need to break permission inheritance at the list level.
As MSDN states, then WriteSecurity has 1 of 3 states possible:
1 — All users can modify all items.
2 — Users can modify only items that
they create.
4 — Users cannot modify any list
item.
But if I want behavour nr. 2 plus users can modify items that are assigned to them? Well if I grant a user full permissions (put in owners group) for list, then those can edit any item (not good). So why wouldn't it work by setting item level permission "full control" just for AssignedTo user (good)? I did, but that didn't help - access denied.
I want exactly the functionality as stated in question "Automatically set list item permission, after new item is created", quoting:
Every users (Supervisor and team members) can see any tasks.
Supervisors can edit any tasks
Team members can only edit their own tasks (tasks that were assigned to them, or created by them)
but although answer has been accepted, the solution does not provide a way for users to edit items assigned to them or items created by user.
Help is appreciated, thank You!
Your only way to do this is using Item-Based Permissions. E.g. have a Workflow or Event Handler change the permission on each file/object based on your requirements.
The solution you quote from the other task is simply setting 2 for SPList.WriteSecurity which still doesn't give users the possibility to edit something they have not created, but were assigned to - in this case you will need to give these users permission, e.g. by listening on the "Assigned To" field with an Event Handler (OnItemUpdated) and give the respective person the needed permission.
Furthermore the solution talks about just setting higher permissions for the users who should always be able to edit items (managers), which is a solution, but you do not have the granularity you usually want in situations like these.