TM1 Forum

Hi All!
I've been thinking on how to insure against some mistakes a developer can do while working in Architect. For example: A developer has mistakenly deleted a product element from a dimension that was part of a cube, then all data related to this product have been also deleted. I've created a process so the developer would be deleting elements only using a process which would copy the product element and all related data to additional cube so it can be copied back. This thing, however seems to be quite inconvenient.

What approaches do You use guys to secure against unwanted changes/mistakes ?

I would be grateful for any peace of advice !

Thank You in advance

Admin note: Moved to correct forum.

Daniel wrote:What approaches do You use guys to secure against unwanted changes/mistakes ?

Strict segregation of DEV / QA / PRD environments with a clear change policy and appropriate security models in place. Anyone with Admin access can do whatever they like, even if you give them tools that are meant to prevent them from wreaking havoc, so it's imperative to reduce the number of people who have standing Admin access to your production environment to an absolute miniumum (0 is ideal, but not always achievable). In most places I've worked a few people would be in serious trouble if a developer just went into a production environment and started deleting elements. Normally a developer should have no standing access to PRD. If there is no separate Prod Support team then it might be necessary to let developers into PRD from time to time, but that should be controlled by some sort of break-glass solution.

qml wrote:

Daniel wrote:What approaches do You use guys to secure against unwanted changes/mistakes ?

Strict segregation of DEV / QA / PRD environments with a clear change policy and appropriate security models in place. Anyone with Admin access can do whatever they like, even if you give them tools that are meant to prevent them from wreaking havoc, so it's imperative to reduce the number of people who have standing Admin access to your production environment to an absolute miniumum (0 is ideal, but not always achievable). In most places I've worked a few people would be in serious trouble if a developer just went into a production environment and started deleting elements. Normally a developer should have no standing access to PRD. If there is no separate Prod Support team then it might be necessary to let developers into PRD from time to time, but that should be controlled by some sort of break-glass solution.

Thank u for your reply, we acutually have separated environments, the thing I don't know if there are other ways on how to quickly redo action as deleting element from dimension apart from using a process.

Daniel wrote:Thank u for your reply, we acutually have separated environments, the thing I don't know if there are other ways on how to quickly redo action as deleting element from dimension apart from using a process.

In TM1 procedural things like that are generally done using TI processes. Not sure if it's more 'inconvenient' than any other way e.g. using API programming. Once you have a code library, either your own or Bedrock, there isn't much new code that needs to be created. Even for the interface you can e.g. use a websheet to invoke your process and control its parameters, so that it can be a decent user experience.