I came across a problem:
As a member of the admin-group I am not able to write on n-elements in the Cube Viewer. They're all grey. No rules are applied. I am using TM1 9.5.2 with the latest Service Pack.
I would be grateful for any advice
Thank you and best regards,
Konstantin
Last edited by rks1 on Thu Jun 13, 2013 1:30 pm, edited 1 time in total.
rks1 wrote:
I came across a problem:
As a member of the admin-group I am not able to write on n-elements in the Cube Viewer. They're all grey. No rules are applied. I am using TM1 9.5.2 with the latest Service Pack.
Did you right click on the cell and choose the "Edit Status" menu option?
It's the German version; it says "Zelle kann nicht bearbeitet werden". Translated it means something like "Cell not editable".
By the way: Other cubes work just fine. We copied this cube and the Security Cubes from the production server to the development enviroment. The production still runs with 9.4.1.
rks1 wrote:It's the German version; it says "Zelle kann nicht bearbeitet werden". Translated it means something like "Cell not editable".
I've never seen a dialog come up from that menu item which doesn't give an indication of why it isn't editable. I'd be fascinated to see a screenshot of it.
The next suggestion would be using the formula tracer out of TM1 Tools on a slice of the cell. If you definitely don't have rules at all in the cube, I'm suspecting that you really have a consolidation in there. The tracer will check that.
You may check if the cube is locked, or if someone has reserved this cube.
Right mouseclick on cube and then security\lock & reserve. (Sicherheit\Sperren & Reservieren in german version).
In general I agree with Alan, ususally the message gives a hint on what prevents editing the cell.
Gabor wrote:You may check if the cube is locked, or if someone has reserved this cube.
Right mouseclick on cube and then security\lock & reserve. (Sicherheit\Sperren & Reservieren in german version).
In general I agree with Alan, ususally the message gives a hint on what prevents editing the cell.
In the English version at least this also shows up in the dialog.
Of course a localisation bug on Iboglix's part is not entirely beyond the bounds of plausibility. I still recall from version 8 that as often as not the message would show up as the oh-so-useful "No write access to element *". Not sure whether that one has been fixed in current versions.
So you're right, checking the lock status manually is a good idea.
thank you very much for the advice. I followed it with the results shown in the screenshots.
I will now try to copy another instance of the original cube from the application server and see what happens...
I will post the result as soon as I have new information.
Attachments
Displaying the error message while checking the status and the results of the trace formula from TM1 tools.
unlock2.JPG (12.05 KiB) Viewed 9175 times
Right click on the cube to check for Security settings. Reservieren = reserve; Sperren = lock
thank you very much for the advice. I followed it with the results shown in the screenshots.
I will now try to copy another instance of the original cube from the application server and see what happens...
I will post the result as soon as I have new information.
Interesting stuff.
I'd strongly suggest raising a service request with IBM over that one; a dialog that merely shows that the cell "isn't editable" is pretty useless in the overall scheme of things.
There's one other thing that you might try, though I can't think why it would make a difference (though there's some little nagging voice in the back of my mind telling me that I've heard of this before)... if you have any aliases in your view, try turning them off and selecting only the principal names of the elements.
After copying the latest data from the working production enviroment (including the systems cubes), applying the latest hotfix (9.5.2 FP3 HF7) and restarting the service nothing has changed. Also Alan's idea with turning off the aliases resulted in the same error. We will dig further on - reports to follow
Probably, You have element or cell security. And element or cell status is read,lock or reserve for the grooup Admin. Did u check all security cubes for your cubes: }cubesecurity, }elementsecurity for all dimensions, }CellSecurity ....?
If you create clone of your cube, and after you will see gray cell in clone cube at the same place, thats means that your problem is in }elementsecurity.
Otherwise - your problem is in }cubesecurity
Jack wrote:Probably, You have element or cell security. And element or cell status is read,lock or reserve for the grooup Admin. Did u check all security cubes for your cubes: }cubesecurity, }elementsecurity for all dimensions, }CellSecurity ....?
If you create clone of your cube, and after you will see gray cell in clone cube at the same place, thats means that your problem is in }elementsecurity.
Otherwise - your problem is in }cubesecurity
I trust that you read Konstantin's statement that he is in the Admin group.
Admins are affected by locks, which should be manually checked as Gabor suggested given that the edit status dialog is useless in his version. They are not affected by element or cell security. (Or cube security, or dimension security.)
Thank you very much for your time and help trying to help solving this problem.
We solved it. And here's how.
First of all, against all good practise advices I had to use two different versions of TM1. Since I was not using my own PC yesterday I was using the 9.4.1 client. The server runs with 9.5.2. And with it came a new function called Data Reservation. That's also the reason why there was no further explaination whens checking the status.
Another colleague today had a 9.5.2 client and then suddenly there was the hint to Data Reservations while checking the cell status. They are stored in the }CubeProperties control cube and only one of all the cubes (my one) had the "required" value in the DataReservationMode property.
rks1 wrote:Thank you very much for your time and help trying to help solving this problem.
We solved it. And here's how.
Good of you to post the details; there are too many cases where people solve the problem but never indicate how, leaving future readers none the wiser as to how it was resolved.
Posting the resolution may help someone in the future.
