none
SSRS Integrated Mode Report Subscription Permissions RRS feed

  • Question

  • I am using Sharepoint 2010 Enterprise and SSRS 2012 in integrated mode.  I would like users to have the ability to subscribe to reports to be emailed to them.

    In my experience, the "Create Alerts" permission enables the "Manage Subscriptions" option on the dropdown, but does not allow the user to create a subscription.  They can get to the subscriptions page but receive a permissions error when they click "Add Subscription".  I have tried every permission; as far as I can tell, users must have the "Edit" permission in order to add a subscription. 

    I would prefer to not give users the "Edit" permission since this lets them edit report attributes (and even folder names) in the document library.

    As a related issue (but not as important as my first question), users with "Edit" permission are only able to send email subscriptions to themselves.  Site owners can send email to anyone.  Ideally, I would like all users to be able to send email to anyone without giving them any additional privileges.

    Wednesday, April 17, 2013 3:28 PM

Answers

  • Talked to the PSS engineer, and they stated that the Product Group felt pretty strongly on this issue that the change needed to be made due to security concerns (users with Create Alert rights only creating so many subscriptions that it caused a denial of service on the SSRS server, for example).  However, he will see if it is possible to re-start the conversation with the Product Group.

    The TechNet documentation is supposed to be updated, but even that can take quite some time.


    SharePoint - Nauplius Applications
    Microsoft SharePoint Server MVP
    MCITP: SharePoint Administrator 2010

    -----------------------
    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Thursday, April 18, 2013 7:15 PM
    Moderator

All replies

  • I've seen this and it appears to be a known issue with users, even with Create Alerts right, cannot create their own Subscriptions without Edit rights to the item.

    As to managing other's subscriptions, that requires the Manage Alerts right on the Site, which allows the user to manage any other user's alerts (and SSRS subscriptions).  See http://technet.microsoft.com/en-us/library/bb283182.aspx for a mapping of SSRS permissions to SharePoint permissions.

    EDIT: I've opened a support case on this.


    SharePoint - Nauplius Applications
    Microsoft SharePoint Server MVP
    MCITP: SharePoint Administrator 2010

    -----------------------
    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.


    Wednesday, April 17, 2013 5:16 PM
    Moderator
  • Thank you for opening a support case about the "Edit" issue.  Will you post the results of the case in this thread?

    As far as the email issue, we don't necessarily want users to be able to manage the subscriptions of other users.  We want them to be able to create their own subscription and specify a recipient other than (or in addition to) themselves.

    Thank you for your help; the document you provided is useful.

    Thursday, April 18, 2013 2:36 PM
  • Absolutely I'll respond here.

    As far as CC/BCC options for email, again that requires the Manage Alerts right.


    SharePoint - Nauplius Applications
    Microsoft SharePoint Server MVP
    MCITP: SharePoint Administrator 2010

    -----------------------
    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Thursday, April 18, 2013 3:30 PM
    Moderator
  • Take a look at http://blogs.msdn.com/b/psssql/archive/2012/08/16/sharepoint-adventures-accessdeniedexception-when-a-user-tries-to-add-subscription.aspx, the PSS engineer pointed this out to me.  Looks like it is by design.

    SharePoint - Nauplius Applications
    Microsoft SharePoint Server MVP
    MCITP: SharePoint Administrator 2010

    -----------------------
    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Thursday, April 18, 2013 6:36 PM
    Moderator
  • Talked to the PSS engineer, and they stated that the Product Group felt pretty strongly on this issue that the change needed to be made due to security concerns (users with Create Alert rights only creating so many subscriptions that it caused a denial of service on the SSRS server, for example).  However, he will see if it is possible to re-start the conversation with the Product Group.

    The TechNet documentation is supposed to be updated, but even that can take quite some time.


    SharePoint - Nauplius Applications
    Microsoft SharePoint Server MVP
    MCITP: SharePoint Administrator 2010

    -----------------------
    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Thursday, April 18, 2013 7:15 PM
    Moderator
  • Thank you for your help with this issue.

    "The thought behind this was also that, in most organizations, creating a subscription is a relatively high-privileged operation since it could have some performance impact and could affect the security of the data and stability of the server."

    In my organization this is not the case (we carefully restrict access to the report itself, anyone who can run it can create a subscription to it).  However, I can understand why the decision was made to do it that way.  In a perfect world, we would like to be able to control the two permissions independently of one another.

    Thanks again for your help!

    Thursday, April 18, 2013 9:21 PM
  • Hi Trevor and Kevin, 

    Did you end up getting a solution for this?

    We have completed moving all of our reports (and most of SharePoint) from a SP-2007 SSRS-2008  to a SP-2013 SSRS-2012 environment and we heavily rely on a self service subscriptions for our users. This is a real deal breaker for us. We can not let the users edit the column data in the report library because there is workflow hanging of it.

    Any workaround or solutions would be greatly appreciated :-)

    Cheers,


    Christopher

    Monday, May 12, 2014 9:52 AM
  • Christopher,

    I'm afraid everything I know about this issue is documented here. 

    We make it work by storing our report definitions (descriptions and details) in another list.  That way, the report library only has the report title and link to the report definition.  If a user edits the title or link I receive an alert and remove their edit permissions.  So far that has not happened.

    The view of reports uses a linked view to display the report definition in the list.

    Hope that helps.  It's a frustrating issue for sure.

    Kevin

    Monday, May 12, 2014 3:00 PM
  • @Kevin:  I'm not sure I understand your workaround - does it still allow end users to create/manage their own subscriptions but NOT do anything else such as Manage Data Sources, Manage Parameters, etc, that become available when users are given Edit Items permission? Any info appreciated!

    @All:  We are a company of 850 or so, and have implemented the self-service model of subscription mgmt - meaning that any user in our existing SharePoint 2010 farm (2008 R2 SSRS backend) can create/modify their own alerts plus also do the same for other users. These users are all in the Visitors group - i.e. Read only, not in Contribute. They have been well-trained and use this self-service subscription feature extensively.

    One of the primary reasons we chose SharePoint-integrated SSRS several years ago was that Microsoft really sold us on this great feature of self-service subscriptions. So, this "by design" change is very unfortunate for our specific environment/usage needs and seems not very well considered in general.

    Wednesday, June 4, 2014 7:59 PM
  • @Eric: No, it does not solve the problem of users being able to edit parameters and data sources.  It only solves the issue that Christopher was having regarding column data attached to the report library.  We simply store all the information about the report (such as definitions of terms, screenshots, etc.) in another list that is joined to the report library.  By making that list read-only, all of that information is protected.  If a user does break the report by editing the parameters we can delete the report, re-deploy from our solution, and re-connect it to the definition.  Of course we would also have to re-create any subscriptions (we have never had to do this, but it is how we can be sure users can't permanently destroy anything).

    We have taken away the "Modify Alerts" permission.  This prevents users from editing the subscriptions of other users, but also makes it so they can't send subscriptions to multiple people (such as a supervisor to employees).  In that case, we have them create the subscription and then contact us to have us add the additional recipients to the subscription.

    It's far from ideal, but it works for us.

    Wednesday, June 4, 2014 8:10 PM
  • @Kevin:  Thanks for the fast and informative reply!

    How do you know if a user modifies any of the SSRS-specific stuff available in the drop-down menu on a deployed report? Per my testing, unfortunately all the SSRS configurations seem to be "outside" the SharePoint alerts and document management structure. I was hoping SharePoint alerts and content approval would be a way to mitigate the risks of users making unwanted changes, but that's doesn't work.

    Any ideas on how to be alerted when these types of configurations are changed? Maybe a query directly against the SSRS backend databases?

    Wednesday, June 4, 2014 10:14 PM
  • @Eric: That is correct.  Changes to the data sources and data sets are not picked up by SharePoint alerts.  You could probably query the backend database if you really need to know about changes.  We just rely on users to tell us if something has stopped working.

    The tables do not include a modified by or modified on field, but I'm sure you could come up with some sort of logging.  There are a couple delivered views that provide a good starting point in the ReportServer DB.  They are ExtendedDataSets and ExtendedDataSources.
    Wednesday, June 4, 2014 10:23 PM
  • @Kevin: thanks, we'll take a look.

    We just got off a call with a MS Premier Field Engineer about all this, and he unfortunately wasn't able to add anything to this discussion beyond what we already seem to know.

    One suggestion he had though was to research if SP2013 SP1 + SQL Server 2014 adds any further permission level capability - he didn't know but was going to look into it.

    Anyone know if SSRS 2014 improves this situation?

    Friday, June 6, 2014 5:38 PM