Locking down cube area from change incl TI procs/admins

[John Hammond]

If the cube area is defined by a single dimension then you would place a lock on the dimension element.

If the cube area is defined by multiple dimensions then you would have to use a security cube. However the highest level of protection that you can put on the area is 'READ'. (NB 'ADMIN' gives admin capability to the security group - and does not lock against the ADMIN)

Even if you place READ against the ADMIN group, it is completely ignored by ADMINs and TI processes which run at Admin privilege.

I am on 9.0, so I was wondering if this is a problem fixed in later releases. Or is there some nifty way round the problem - the only way I can think of is to introduce a dummy lock dimension that is the catenation of the dimensions you need to lock by so you can use dimension locking to solve your problem but I think that is too clumsy.

Regards John

[tomok]

Why can't you create a CellSecurity cube for the cube in question and apply the LOCK there?

[John Hammond]

sorry should have elucidated further.

You have to use a cellsecurity cube to do multi-dimensional security.

However putting LOCK in the cellsecurity cube does not Lock that group but grants that group 'LOCK' privelege to that cell.

Honestly I thought the exact same as you Tomok but if you try it you will find that LOCK does not stop an Admin or TI process modifing the data. (At least in 9.0).

Thanks for your prompt reply though.

[mattgoff]

I don't have an answer to your question, but I do wonder why you can't adjust things to avoid giving admin access. Can you explain more about the situation?

Matt

[mvaspal]

I am on 9.0, so I was wondering if this is a problem fixed in later releases.

Starting from 9.5.? (2 maybe), you can use data reservation for such purposes. It is quite similar to the 'Lock' function for dimension elements just you can do it for a combination of dimensions. It also prevents Admins to edit data reserved by other users.

[John Hammond]

matt

The problem is that admin access is implicit when you run a TI. In addition dimension locking does stop admins.

Mvaspal

That sounds an interesting work-around. Can you reserve by rules or using TI processes rather than just manually?

Thanks to all responses.

[Duncan P]

http://publib.boulder.ibm.com/infocente ... tions.html

Never used them myself though.

[mvaspal]

I have also never used in a PROD environment just tried it out. You can use it with TI only.
TM1 Contributor applies data reservation on the approval hierarchies.

[Edward Stuart]

The issue we have is that our users want to copy from a dynamic version to a static version (Actuals to Actuals_Reported), this process has been in operation for years without issue. However, we have a new requirement to lock down the Actuals version by a selection of additional dimension elements.

We can apply the standard READ access to the relevant cross sections, however, ADMINs can still amend the data. This is not an issue per se but we do have some TI Processes which can amend the data that is to be locked down.

We cannot restrict access to the processes as they run on a pMonth/ pYear basis, we do not want to continually amend the TI processes to ensure they do not overwrite any data.

Data Reservation would appear to resolve our issue:

See TM1 Developer Guide > Data Reservations and TurboIntegrator processes and chores

You should understand the following considerations when using Data Reservation
and also running interactive (non-scheduled) and scheduled TurboIntegrator (TI)
chores/processes:

Some of this behavior is different depending on which Data Reservation mode is
being used and whether the chore is run interactively or scheduled.

Interactive Processes and Chores

When a user interactively runs a process or a chore, for example from the TM1
user interface, then that process/chore runs as that user.

- For REQUIRED mode, this means that the process/chore can write only to data
defined in the DRs held by that user.

- For ALLOWED mode, the process/chore can write to any cell that is either
contained in a DR for that user or has the appropriate security rights for that
user, but the process/chore cannot write to cells contained in another user's DR.

The following behavior is the same for both the REQUIRED and ALLOWED Data
Reservation modes.

- If a write operation in the Interactive process/chore conflicts with the Data
Reservation of another user, then the process/chore fails and an error message is
displayed to the user.

- To run a process that acquires and releases DRs, the user running the process
must belong to a user group that has the ManageDataReservation capability set
to GRANT.

All well and good, but we are currently using 9.0 and this functionality is not available.

To confirm the rights given to TI processes see TM1 Turbo Integrator Guide > Editing Advanced Procedures

TurboIntegrator security is assigned by administrator

The admin who creates a TurboIntegrator process assigns the security privileges to
the TurboIntegrator process.

A TurboIntegrator process can be created only by an administrator, who has the
Admin privileges required to create a process. The administrator can assign rights
to the process. The TurboIntegrator process has those rights regardless of the rights
assigned to any user running the process.
Non-admin users need to have Read access to a TurboIntegrator processes in order
to see the process in the interface and to execute the process. But the
TurboIntegrator process itself retains the rights assigned by the administrator.

For example, consider a user and an administrator where:
- User U1 has only Read access to cube_1.
- The administrator creates a TurboIntegrator process that does a CellPutN into
cube_1, which requires Write access to the cube.
- The administrator gives U1 Read access to the TurboIntegrator process.
- U1 can run this TurboIntegrator process and it will do the CellPutN even though
the user only has Read access to cube_1. The same result is obtained if U1 has
None access to cube_1.
- A user with only Read access to a TurboIntegrator process can only view and
execute the process. The user can't edit the process to change the value being
sent or the location where data is being put.
- The conditions described above are also true when a user executes a
TurboIntegrator process from within a chore.

To prevent U1 from being able to access this TurboIntegrator process, the TM1
administrator should not give U1 Read access to the TurboIntegrator process.

Note that the quotes above were taken from the 10.1.0 documentation.

[mattgoff]

The problem is that admin access is implicit when you run a TI. In addition dimension locking does stop admins.

The issue we have is that our users want to copy from a dynamic version to a static version (Actuals to Actuals_Reported), this process has been in operation for years without issue. However, we have a new requirement to lock down the Actuals version by a selection of additional dimension elements.

We can apply the standard READ access to the relevant cross sections, however, ADMINs can still amend the data. This is not an issue per se but we do have some TI Processes which can amend the data that is to be locked down.

We cannot restrict access to the processes as they run on a pMonth/ pYear basis, we do not want to continually amend the TI processes to ensure they do not overwrite any data.

I'm not 100% understanding your scenario, but I believe you can still work around this issue by having your process check either a control cell or an entire lookup cube (if your locked/open requirements are more complex) to avoid needing to hardcode the dates in TI. Then, if TI would write to a prohibited cell, ItemSkip it.

Personally, I have a single cell, "Forecast_Start_Period", in a control cube-- this period and later (we use a single time dim) are open for user writing, everything earlier is copied (by rule in our case) from the Actuals scenario.

Matt

[mvaspal]

http://www-01.ibm.com/support/docview.w ... wg27024861

As of 10.1 FP1, data reservation will not prevent admins from data input.
Which on one hand is fine because it was really complicated to write to Contributor cubes reserved by users (for example overnight TIs, chores); on the other hand it used to be a fine tool for preventing admin users from direct data input.