This error is sometimes seen while viewing a listing in InterSystems IRIS Business Intelligence: ERROR #5540: SQLCODE: -99 Message: User <USERNAME> is not privileged for the operation (4)
As the error suggests, this is due to a permission error. To figure out which permissions are missing/needed, we can take a look at the SQL query that is generated. We will use a query from SAMPLES as an example.
In part 1 we started working on a security model for DeepSee and create a user type having privileges typical of end users. In this part we are going to create a second user type with ability to edit and create DeepSee pivot tables and dashboards.
I have a few cubes and numerous dashboards and I am ready to deploy them to our end users and administrators. How to configure DeepSee so that users don’t disrupt each other’s areas and are restricted from using functionalities specific to developers?
In old Caché versions it was possible to create a new role based on predefined %Developer by copying it and adding some resources as needed. It was true at least from 2010.1 to 2015.1.
After upgrade from 2015.1.4 to 2017.2.1 it turned that it's only partially true now. User with a "New-Developer" role can enter Studio and open existing cls/mac/etc for editing and everything is OK unless he tries to create something new (Ctrl-N), than he gets a pop-up with %msg: <User xxx does not have enough privilege to execute stored procedure %CSP.StudioTemplateMgr_Templates>
In part 1, part 2, and part 3 parts of this series we set up three user types. In part 4 we saw how to secure model elements and DeepSee items. In this last part of the tutorial we conclude with some remarks on DeepSee security and troubleshooting tips. In particular, we see how pivot tables in User Portal can be "hidden".
In part 1, part 2, and part 3 of this series we set up three user types. In this part of the tutorial we see how to secure model elements (such as DeepSee cubes) and DeepSee items (such as a folder containing pivot tables and dashboards in the DeepSee User Portal).
In part 1 and part 2 of this series we set up two user types, simpleuser and poweruser. In this part of the tutorial we create one last user type having privileges typically needed by an administrator/developer in analytics.
Imagine that your .NET project uses the Caché DBMS and you need a fully-functional and reliable authorization system. Writing such a system from scratch would not make much sense, and you will clearly want to use something that already exists in .NET, e.g. ASP.NET Identity. By default, however, this framework supports only its native DBMS – MS SQL. Our task was to create an adaptor that would let us quickly and easily port Identity to the InterSystems Caché DBMS. This work resulted in creation of the ASP.NET Identity Caché Provider.
This post is meant to provide a quick possible explanation for a very perplexing problem.
Scenario: You’ve just created your own administrative user in your 2014.1 (or later) instance of Caché. You gave it every possible security role (including %All), so it should in theory be able to do anything within the instance.
You’ve written a very advanced routine with a break command in it for debugging: