I get an error in both v7 and v8 when trying to run a SOAP API query using an account that is set to read-only.
I’m not sure why this would be a problem, but can this be changed? Otherwise, I’ll have to provide an account for someone to pull this data which will allow more access than I would like.
I haven’t tried changing the options within the Roles (v8), but as the Read-only role just limits the ‘edit public filters, reports and labels’ entry, there doesn’t seem to be a way around it (via the options given).
I believe that since the the custom reports are powered by session relevance (and so is the SOAP API), these privileges are tied together… I can doublecheck…
Ben - Any feedback on this? I definitely think this needs looking into, especially due to the issue, below.
I found it surprising that the Read-Only role in v8 doesn’t seem to be RO, in that I was able to have an account using it create a private report. After looking into it, I noticed that the built-in Read-Only account isn’t really read only, as the option “Can create and save custom content.” set to “Yes”. Hmm. That’s not what I expected.
So…I created my own “Read-Only, and yes, this time I do mean just RO” account, which has the “Can create and save custom content” set to “No”. Sadly, this also allows the user to create reports. {sigh}
Lastly, Im concerned that the admin rights of accounts on the web reports server don’t have access to the reports of all users, which is a problem if some of them are left as Private. That is, if we enable access via AD, then there will be many accounts that I might not have access to, where I might want to get access to the reports they created( or be able to delete once the account is disabled or deleted). Would I have to get access to the database (which I don’t currently have), in order to find the table where they exist and copy/delete them?
Our role terminology appears to have made an awkward transition from the previous major release, so I have filed a bug to work on the language.
As currently defined, a “Read-Only” user cannot modify any public reports (i.e. any reports created by other users), and can only create private reports. No one else can see these private reports, so they won’t muddy up anyone else’s view.
The “can create and save custom content” simply refers to access to the “custom” page under “Explore Data”, which can only be seen if the box is checked.
If you delete the user, his private reports will also be deleted.
Thank you for looking into this and providing more detail.
The one other piece of this question goes back to my initial problem: you cannot use a Read-Only account to run SOAP API query.
I don’t really understand why, especially when you’ve mentioned that the rights the account has aren’t actually ‘RO’, but only partially restricted. Surely running and creating reports (and saving) in web reports would require as much access rights (if not more) than running a query via the SOAP API?
Apparently this restriction is another relic of the old platform. It was put in place to protect the server from a few potential performance issues. These issues seem to have been reduced in version 8, so our engineers filed a bug to remove the restriction.
We appreciate you bringing all of this to our attention.