1

So I'm developing an event management system at the moment where there are two user groups, "editors" and "attendees". By registering for an event, the SPUser is added to a list "attendeeList" which has the lookupfield "event". Works fine (using runwithelevatedprivileges for registering process) except this one thing:

On default.aspx, an attendee should have a List view webpart called "My Registrations" which should show the events he registered for. I did this via Standard List webpart from the default webparts collection in SP2010. (I should have mentioned that I was dumb and I saw that attendees shouldn't have access to attendeeList later on, so this worked before my access changes to group Attendees). My problem is: I get access denied for this List view webpart on default.aspx if an attendee logs in after doing my changes and I don't know how to change this.

Now my question: Is it possible to change the access for this view only? Preferrably without coding another visual webpart itself? I don't find such an option at the moment and hope it is out there and some of you could help me. If there's not, I hope there'll be another solution and it would be great if you could give me a hint.

Best regards, Dominik

Improve this question
4
  • Is there any reason to block access to the list items for the attendees users? Why should they have access to a set of data if they view the homepage but receive an access denied error if they try to view the same info from another page? Wouldn't a item-level permission be a better solution? Commented Jan 16, 2013 at 8:55
  • They should only have access to "their" data sets for unregister purposes and for easy unregistering without loking up the whole "events" list. My VWPs are only on top of ViewForm.aspx on event list... But they should not be able to look up every user who has registered for every event. But... I'll write an answer. Solved it ;) Commented Jan 16, 2013 at 9:48
  • 1
    Imho I see two option. First: use the list as a pure data storage without any visibility to the user and build a full custom web part to manage the info. Second: use the list as is and filter out the permissions on a by-item level. Commented Jan 16, 2013 at 9:54
  • thanks for your suggestions. I did it now as you could see in my answer :) Commented Jan 16, 2013 at 10:29

1 Answer 1

Reset to default
1

I got it working now by "reversing" the authentication logic for attendeeList.

Now I only give editors access to allitems.aspx via deleting Lists/allitems.aspx and using the same aspx, but out of a... oh, have a look at this tutorial, it's explained better there ;) http://khurrampunjwani.wordpress.com/2012/08/01/how-to-set-view-level-permissions-out-of-the-box-in-sharepoint-2010-2/ this is what I've done.

Now users "have" read permissions and my webpart is working, but cannot view the allitems.aspx, only the "myregistrations.aspx" - as it should be. Works like a charm :)

Edit: This is potentially a security break, so please read the comments beyond this answer! More Info is highly appreciated by some more experienced guys (or some ppl who used this and researched this solution ;) )

Improve this answer
6
  • Just to see if I have understand: instead of protecting the items in the list with an item level permission you move the view .aspx file to another list and protect it? interesting solution, must keep it in mind. Commented Jan 16, 2013 at 10:28
  • It is the same list, actually. Problem was, user should "have" read-rights for the list, but only for the datasets he's concerned. E.g. User registers for event "A". So he should see his registration got "A" somewhere, so he needs access to his Listentry for "A". I created a List view "myreg.aspx" and gave users read-rights for the list. Then I copied the "normal" allitems.aspx (no access for attendees) to a document library and deleted the old one. After that I changed access right to my "document" allitems.aspx and moved it back and deleted the "old" view-entry in UI. And: works. Commented Jan 16, 2013 at 11:44
  • Got it. Interesting trick. Must test it when I get some time (seems a little unsupported, so try to test it somewhere safe before deploying it to prod). Commented Jan 16, 2013 at 11:54
  • 1
    I have to mention that with my solution, my "attendees" now "have" access to the "myregistrations.aspx" - page and so they could add notifications for my (whole) attendee list which is not wanted. So I don't use the solution from the answer now, because it's not secure enough for my situation. I'll write a custom vwp for this. It's not that much work, only one linq-query in runwithelevatedprivileges where current user == attendeeList["attendeeName"] or something like that. Commented Jan 16, 2013 at 15:26
  • Probably more safe, too. I have the feeling the other solution may break something somewhere. Don't know what, just a case of spider sense tingling. Or I simple know what kind of beast is SharePoint. Commented Jan 16, 2013 at 15:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.