User not authorised on favorite

I have a view only user. I’m trying to share a favorite with this user. The favorite shows up for the user, but when he tries to view it, he only gets a “You are not authorized. #63538” error. This favorite is a transaction mode listing. If I change the favorite to a summary graph, the user see the correct count under his alerts, but clicking on the alert again gives the above error.

If I add the favorite to a dashboard, the user sees the detail on the dashboard, so it doesn’t appear to be a permissions issue.

I cannot figure out what I am missing in getting this user to view this favorite.

After a bit more testing, it appears that it’s the transaction mode which is causing the issue. As soon as I change the favorite to Transaction Mode, the “viewer” user gets the “You are not authorized” error. Interesting though that the user can see the transaction mode detail when it is saved to a favorite. The user just cannot view the favorite directly. I my question now is if this behavior is intentional.

@aaron.roma I am currently experiencing the same issue. I created a favorite which is using “Transaction Mode” and then shared it with a user (Viewer). When the user tries to open the favorite, they get "You are not authorized. #49759

Did you find out anything more on this issue?


Justin - you may want to look at the users profile and make sure they have access to all measures & dimensions. It may be unrelated, but I had users unable to access favorites due to measure/dimension level restrictions. However, I don’t recall if they had an error number.

@Justin No, unfortunately nothing ever came from this. The last I heard was they were going to look into it to see if this was a bug or working as expected, but never heard anything back. I just checked, and it still works the same. A favorite in transaction mode throws the “not authorized” error, but that same favorite in a dashboard works just fine. We ended up just working around the issue by using dashboards to view those favorites.

@aaron.roma thanks for the reply. We also used the same work around.