Hello,
The question might have been asked in the past, I could not find any topics and no luck with Google either.
If we migrate TM1 objects from development to production, is there any way to block users from logging in ?
Users know that the application is down for maintenance but still they could log in.
Any suggestions please, other than blocking access to the admin host, since the developers need to migrate the objects (so some users still need access to TM1 obviously) ?
Thanks,
Wim
Block TM1 usage during upgrade / migration
-
- MVP
- Posts: 3113
- Joined: Mon Dec 29, 2008 6:26 pm
- OLAP Product: TM1, Jedox
- Version: PAL 2.0.9.18
- Excel Version: Microsoft 365
- Location: Brussels, Belgium
- Contact:
Block TM1 usage during upgrade / migration
Best regards,
Wim Gielis
IBM Champion 2024
Excel Most Valuable Professional, 2011-2014
https://www.wimgielis.com ==> 121 TM1 articles and a lot of custom code
Newest blog article: Deleting elements quickly
Wim Gielis
IBM Champion 2024
Excel Most Valuable Professional, 2011-2014
https://www.wimgielis.com ==> 121 TM1 articles and a lot of custom code
Newest blog article: Deleting elements quickly
-
- MVP
- Posts: 1815
- Joined: Mon Dec 05, 2011 11:51 am
- OLAP Product: Cognos TM1
- Version: PA2.0 and most of the old ones
- Excel Version: All of em
- Location: Manchester, United Kingdom
- Contact:
Re: Block TM1 usage during upgrade / migration
I had a similar requirement at one point that meant users needed to “lose” access during certain super user tasks, basically so they didnt see the work in progress that was a super uaer setting up the system - it was a long time ago but I basically had 2 TIs.
One ran at the start which copied the }ClientsGroups cube to a copy cube then removed all access except certain special groups.
This meant standard users could still connect but wouldnt have access to anything. When it was ready to be opened up again the super user ran the second process which just reinstated everyones groups.
That was mode 1 security, if you were working with CAM groups it would need to do something different (e.g remive that groups access to cubes/dims etc)
It wasnt particularly elegant but it got the job done.
One ran at the start which copied the }ClientsGroups cube to a copy cube then removed all access except certain special groups.
This meant standard users could still connect but wouldnt have access to anything. When it was ready to be opened up again the super user ran the second process which just reinstated everyones groups.
That was mode 1 security, if you were working with CAM groups it would need to do something different (e.g remive that groups access to cubes/dims etc)
It wasnt particularly elegant but it got the job done.
Declan Rodger
- paulsimon
- MVP
- Posts: 808
- Joined: Sat Sep 03, 2011 11:10 pm
- OLAP Product: TM1
- Version: PA 2.0.5
- Excel Version: 2016
- Contact:
Re: Block TM1 usage during upgrade / migration
Hi
In our case, all the security in the main security cubes such as }CubeSecurity and }ProcessSecurity is rule derived. We find that this is easier to manage when it comes to promoting changes than promoting data values such as READ, etc.
We then have a central control cube with a flag for Make TM1 Read Only. Security ensures that only admins can change this.
When we set this flag a rule at the top of the }CubeSecurity cube rules sets everyone's rights to Read Only, so that only administrators can change anything - you could of course exclude a super user group from this just by using CONTINUE to that the normal security rules apply.
The rules in }ProcessSecurity are the same but in that case they set everyone's access to NONE to prevent them running a process, eg from an Action Button.
In this way users can still use the system but cannot change the data.
We have one process Make TM1 Read Only that sets the flag and runs a security refresh, and another Make TM1 Updateable that clears the flag and runs a security refresh.
Regards
Paul Simon
In our case, all the security in the main security cubes such as }CubeSecurity and }ProcessSecurity is rule derived. We find that this is easier to manage when it comes to promoting changes than promoting data values such as READ, etc.
We then have a central control cube with a flag for Make TM1 Read Only. Security ensures that only admins can change this.
When we set this flag a rule at the top of the }CubeSecurity cube rules sets everyone's rights to Read Only, so that only administrators can change anything - you could of course exclude a super user group from this just by using CONTINUE to that the normal security rules apply.
The rules in }ProcessSecurity are the same but in that case they set everyone's access to NONE to prevent them running a process, eg from an Action Button.
In this way users can still use the system but cannot change the data.
We have one process Make TM1 Read Only that sets the flag and runs a security refresh, and another Make TM1 Updateable that clears the flag and runs a security refresh.
Regards
Paul Simon
-
- MVP
- Posts: 3113
- Joined: Mon Dec 29, 2008 6:26 pm
- OLAP Product: TM1, Jedox
- Version: PAL 2.0.9.18
- Excel Version: Microsoft 365
- Location: Brussels, Belgium
- Contact:
Re: Block TM1 usage during upgrade / migration
Hi all,
Thanks, that gives food for thought.
I think I will make the users read only (}ClientProperties cube, ReadOnlyUser = 1).
Next to that, process security can be set to NONE in a rule.
It's CAM security.
Many thanks,
Wim
Thanks, that gives food for thought.
I think I will make the users read only (}ClientProperties cube, ReadOnlyUser = 1).
Next to that, process security can be set to NONE in a rule.
It's CAM security.
Many thanks,
Wim
Best regards,
Wim Gielis
IBM Champion 2024
Excel Most Valuable Professional, 2011-2014
https://www.wimgielis.com ==> 121 TM1 articles and a lot of custom code
Newest blog article: Deleting elements quickly
Wim Gielis
IBM Champion 2024
Excel Most Valuable Professional, 2011-2014
https://www.wimgielis.com ==> 121 TM1 articles and a lot of custom code
Newest blog article: Deleting elements quickly