Business Case :
Every time Permission Inheritance is broken, I need certain custom things (through code) to happen on my SharePoint environment.
Details: If user clicks on Site Settings -> Site Permissions -> "Stop Inheriting Permissions", I need a custom code called so that certain actions can be performed like changing the group name, make an entry in the global list etc...
Image : http://i.stack.imgur.com/z2eo6.png
Even Receivers are not new in SharePoint 2013. They did exist in previous versions of SharePoint. But they are still limited and I could not see one which gets triggered with users' action of clicking that button i.e. Stop Inheriting Permissions. I can capture "Updated" event and check programmatically if permission inheritance was broken but that will fire every time which to me is dirty solution.
If above is not possible then what are other possible alternatives ?
One I know is - Hide "Stop Inheriting Permissions" and create a custom one which will let me achieve above Business Case. But I want to minimize custom coding as much as possible.
Found out an answer the same day I posted the question.
SharePoint does offer class SPSecurityEventReceiver which has required Event Receivers.
(1) InheritanceBreaking (2) InheritanceBroken (3) InheritanceReset in my case.
Hope that helps someone !
Related
I have exported a solution from one of my existing CRM Online instance, and imported to another new instance which is also CRM Online 2016.
The solution contains customized Opportunity entity (forms, views, fields, processes, etc), and a custom Security role.
The solution contains one custom field "Follow up Contact" which is of lookup type and referencing to Users entity.
After importing the solution, I have assigned one of the user to the custom security role in new instance.
Now, when I try to create a new opportunity, and try selecting "Follow up Contact", I am seeing no user in the list, whereas the associated view is expected to display at least 5 users. Also, when I try clicking on "Look for more records", I get following error -
"You do not have sufficient privileges to open this Lookup dialog box."
Whereas, users with same security role in the source solution can see the items in the "Follow up Contact" dropdown, and also that "Look for more records", work fine for them.
Any idea what could be the possible reason? Are there any changes in terms of security roles in latest upgrade of CRM Online?
Well strange things do happen!!
I opened the form in designer mode.. disabled the execution of the particular method which contains scripts for setting default value to the lookup control.
Published the solution.
Then again, enabled the script execution...
and to my surprise, the lookup field started working...
Just had this problem and here is what worked for us.
We had a custom entity that was related to the out-of-the-box Account entity. We had 3 lookups on that custom entity to Account. Even with System Administrator role, none of our users could get any records to return from the lookup search and we got the error message specified in the title.
We ended up deleting ONE of the lookup fields (picked the one with least dependencies). We added that field and its dependencies back in. It was annoying manual process, but after this all THREE of our lookup fields were fixed.
I'm guessing the Account-Custom Entity relationship XML behind the scenes was corrupted somehow, and deleting/recreating cleaned it up.
How can I disallow adding item or document to a list or document library? Due to some other feature scenario I cannot break role inheritance and have custom permission set for the list. Today, we restrict the addition using event handler (Item adding) – but this leads to poor UX.
Is there a way to have Role inheritance for a list and still have a base permission mask? Something like, allow everything that parent web offers but not X,Y,Z. Breaking role inheritance in the traditional way introduces the problem of explicit User and role management. Having a SPGoup hold an another SPGoup could help here, but that too is not possible. Let me know your suggestions.
I think you are asking to allow a user to have add permissions to the list but not actually be allowed to add to the list. Event receiver is going to be the best way. The only other solution I can think of is to use a custom item form that will do the check.
You can solve your problem by creating a webpart with the below functionality.
Identify the logged user is in admin group. If he is not in that group ganarte a javascript alert that "you have no permission for add new item" and redirect to (location.href="") allitems.aspx page.
And place this webpart in Newform.aspx page.
(add &toolpaneview=2&sharedview=true in in Newform.aspx url for editing page)
Hope this helps. Let me know if you need more help.
Create an IHTTPModule and subclass the context AuthenticateRequest event.
In the AuthenticateRequest routine you can inspect what type of action is happening and then redirect the user to the SharePoint "Access Denied" page. This is exactly how SharePoint does this functionality so the UX experiance would be the same.
If you want my opinion I would go with the way SharePoint handles permissions out of the box and break role inheritiance. Sure it will add new complexities to your life. But, I think you can better manage these complexities with the SharePoint Admin Toolkit and some custom built utilities for managing permissions. I think that is a better solution than what you are trying to do.
Am I missing something here when I suggest: Just hide the toolbar (or specific button) in the view page? That's an painless CSS hook done in the view page or SharePoint Designer
If you are using a custom List Template, you could create a custom View Toolbar Template. However, you probably will not want to use this on an OOTB List Template and it doesn't look like this will work on an existing list.
Even if you implement this, I would still leave the Event Receiver in place in order to prevent URL spoofing.
Is there a way to limit the "edit item" permission in WSS 3.0 to only allow a user to edit his own documents or list items? We need the ability for a user to edit only documents/list items he creates - NOT items that someone else created. So, essentially we need a sub-set of the EDIT permission as well as ADD.
Is this possible in Windows Sharepoint Services 3.0? Is there a way to create custom permissions in code or a feature?
WSS has a basic UI for setting item-level permission on list items, but they hide that from the UI for document libraries. If you go into Settings->List Settings->Avanced settings for a list, you'll see the options to do pretty much what you're asking for. However, on document libraries, that UI is not available. The settings it drives, though are avaiable via the object model.
You could set those same properties for a document library like this:
SPDocumentLibrary onlyOwnLib = theWeb.Lists["DocLibName"]
onlyOwnLib.WriteSecurity = 2;
onlyOwnLib.Update();
And that should about do it. However, apparently that doesn't really set permissions; it just controls what the user can do via the UI. If they had another interface to the library (like via WebDAV) or list (like via the web services), it wouldn't prevent them from editing items they didn't create. If you want true item-level permissions, I think you need to go the event handler route.
This post from Matt Morse explains it in more detail, and he even wrote a command line tool to set the property (plus the .ReadSecurity property) for lists and libraries.
If you added an event handler to the document list you should be able to limit edit rights on that item to the user that created the item.
I often have to copy documents from another system into a list in SharePoint, and in that case the edit rights will be assigned to the system user that transfered the document, unless you use the approach suggested by Kirk Liemohn here
Note that item level permissions on large numbers of documents increase the load on your SQL server quite a lot.
here is the solution for your request.
go to the list -> list settings -> Advanced Settings
you will see the section of
Read access: Specify which items users can read
All items
Only their own
Edit access: Specify which items users can edit
All items
Only their own
None
select the options based on requirement. that's it done..
wanna more click on http:// mastermoss.wordpress.com
This is an old question, however the problem still exists.
A way that has worked well for me in the past is to use a workflow to configure the permissions when the library item is added.
See http://www.sharepointusecases.com/index.php/2010/03/configure-item-level-permissions-for-document-libraries-part-2/ for details.
I believe that permissions like that can be created through the user interface. It depends on the scale and number of list items you have, but you could do one of two things. First (without having to create scripts) you could give everyone a custom "Read" permission access which would not allow them to do everything you can in in the Read permission but allow them to Add Items. Then on an item-by-item basis, click the item -> manage permissions -> (Give the specific user Contribute permissions on their document).
If you're creating a SharePoint list that this will not be practical, you can create a script to traverse through all items, and will verify the user has contribute permissions (otherwise it will set the contribute permission to that user).
Additionally, you could just give each person their own folder.
Give everyone read permissions on the SharePoint list/document library, but give each person full control privileges over their own folder. This will allow everyone to read everything in a list, but create/edit their own documents.
If you want the 'Only their own' permission on a document library, it isn't there out of the box. But I've created a solution at CodePlex that adds this for Document Libraries - check it out at http://moresharepoint.codeplex.com.
We are using the default Task list from a Team Site and would like to only allow those that the Task is "Assigned To" to edit the tasks. How do you go about enforcing this?
When we tried the "Advanced Settings", we found that "Only their own" meant only those tasks created by the current user.
It looks like you need to create an event handler that updates the permission on the Task everytime the assigned user is changed.
Quite a few people have had this problem in the past.
Check out this site for an example of the problems people have had. That said it should work out-of-the-box if you copy content when setting up the Task List.
Looks like, an event handler is the way to go. I found this page in some of my searching and it explains a lot of the problems related to this issue:
Email Notifications and Alerts - Sharepoint Tasks List
Unfortunately, the client wants no custom code and wanted SP Designer workflows and browser based customizations only...
I have a custom action in a workflow and would like to report an error to the user when something goes wrong. What's the best way of doing that?
UPD: Ideally I would like to put the workflow in the error state and log a message to the workflow log. That doesn't seem possible. What's the closest I can get to it? I want to a reusable solution,something that's easy for users to set up when using my custom action in SharePoint Designer.
Added more details to the question.
#mauro that takes care of storing the error, but how do I display the error to the user in a way which makes sense?
#AdamSane That's seems like a rather fragile solution. It's not a matter of setting this up once on a single site. I need something others can add using SPD.
when you throw the error your error handler can then email the user, or better if the list is massive, add the error state to the workflow item - i think this is default functionality though as the error would be mentioned there.
http://www.sharepointsecurity.com/blog/sharepoint/sharepoint-2007-development/fault-handling-in-sharepoint-workflows/
Personally I would log it to either a log file or the event log depending on the issue. I think storing it using a users permissions would be a bad idea, what happens if that user does not have the correct rights? or worse still they get elevated permissions by browsing the list in explorer view?
The log file would be the best way, that way you rely only on the file system being available - you dont have to worry about trapping errors happening whilst connecting to the database etc.
Mauro
Add the error to a hidden list with that users name. Set the visibility on the list (for users) to only read/write their own values. Then use a custom web part or FlexListViewer to view the contents of that list and display it to the user. Once they acknowledge that error, remove it from the list.
If necessary, you can add a different workflow action on that message list, that says pause for 2 days and then email. Whatever, depending on your requirements.
Otherwise you can have a custom db table that you use for pretty much the same thing, this way sharepoint does most of the work for you.
Update This can be packaged up as a feature and deployed to each site as needed. The strengths of this approach (adding a list item to a list, querying, alerting a user, and emailing a user) are all built into the sharepoint itself. In this case you can focus on your custom logic only, while letting sharepoint focus on the implementation details.
If you need the user to take some action as a result of the error (e.g. retrying the workflow) is it possible to create a task for that user with information on the error and the location of the workflow?