Cell security and process in cognos TM1

[ChauBSD]

Hi everyone,

- I have application Approval, contain 4 cubes. I am input data on 2014 year. When I submit level, then data in all year lock.
I can't input data in 2015 year.
- I am want when i submit, data lock only in 2014 year. I try write rule in }cellsecurity_cube.

How do ???

[EvgenyT]

Hi everyone,

- I have application Approval, contain 4 cubes. I am input data on 2014 year. When I submit level, then data in all year lock.
I can't input data in 2015 year.
- I am want when i submit, data lock only in 2014 year. I try write rule in }cellsecurity_cube.

How do ???

Hi There,

You repeatedly post threads that lack explanations, TI/rule codes, examples, cubes structure, relationships, etc.

Please review "Request for assistance guidelines", so people who are willing to help you actually "able" to help you, instead of wasting their personal time.

Regards,

Evgeny

[overflow]

Hi ChauBSD,

Just to help clarify your issue - this is in Contributor, and the issue is with the submission of a node in an approval hierarchy? You would like users to be able to submit one year, but not the following one, as that needs to be open for future input? My response below is based on that assumption.

If you are using an approval application, any submission will lock all the data in that node. You cannot selectively lock only a part of that node with the submission process. Have you considered using a responsibility application? This will not lock data on submission. Refer to the ibm documentation for details:
http://pic.dhe.ibm.com/infocenter/ctm1/ ... types.html

Alternatively it may be worthwhile looking at your cube security, but it would be a reasonably complex update to maintain, unless you had a flag of some kind to indicate that the node was submitted, and therefore the cube security required update.

Hope this starts you on a resolution!

Overflow.

[ChauBSD]

Hi everyone,

- I have application Approval, contain 4 cubes. I am input data on 2014 year. When I submit level, then data in all year lock.
I can't input data in 2015 year.
- I am want when i submit, data lock only in 2014 year. I try write rule in }cellsecurity_cube.

How do ???

Hi There,

You repeatedly post threads that lack explanations, TI/rule codes, examples, cubes structure, relationships, etc.

Please review "Request for assistance guidelines", so people who are willing to help you actually "able" to help you, instead of wasting their personal time.

Regards,

Evgeny

Hi ,

I have application Approval, contain 3 cube. 3 cube input data. Because my customer wanna lock all when submit.

Hinh1.gif (27.65 KiB) Viewed 6824 times

And when i submit , approve planing 2014 . My customer wanna input data 2015. I am usnderstand, when we used application approval lock all when user submit.

Hinh2.gif (18.67 KiB) Viewed 6824 times

This is my structure approval.

hinh3.gif (7.03 KiB) Viewed 6824 times

.

I just wanted to intervene, lock only 2014 year and I can input data of 2015 year. And How to catch submit and reject the status of the cube ????

Thanks your

[overflow]

Hi ChauBSD,

Thanks for the extra detail.

There is no way that you can submit 2014 in this application and leave 2015 open. Submission on a node (such as Binh Durong) will close ALL fields for this node.

You could create a separate cube for 2015, which has the same structure as the one used in the existing 2014 application. Using rules you could draw the information from the current application, and you could put this in a separate application, which would be independent of the submission process. This would allow users then to see their submitted 2014 data in one application, locked as required, with the opportunity to use that to drive their inputs for 2015. To me as this would use the same security as the existing application, this solution would seem the simplest.

Alternatively you could use a responsibility application, which does not lock down for submission, and then create a process to update the cube security for users.

Regards,
Overflow.

[ChauBSD]

Hi ChauBSD,

Thanks for the extra detail.

There is no way that you can submit 2014 in this application and leave 2015 open. Submission on a node (such as Binh Durong) will close ALL fields for this node.

You could create a separate cube for 2015, which has the same structure as the one used in the existing 2014 application. Using rules you could draw the information from the current application, and you could put this in a separate application, which would be independent of the submission process. This would allow users then to see their submitted 2014 data in one application, locked as required, with the opportunity to use that to drive their inputs for 2015. To me as this would use the same security as the existing application, this solution would seem the simplest.

Alternatively you could use a responsibility application, which does not lock down for submission, and then create a process to update the cube security for users.

Regards,
Overflow.

Hi overflow
OMG , I have many cubes and many application approval. ^^. I have data in every year.
Can i use code TI or rules ???

I Am need your advange. Thanks you

[declanr]

This is the biggest flaw of the contributor (applications) stuff in tm1; being able to have only 1 dim for your approval hierarchy renders it useless in a lot of cases.

In your position I would just build my own approval cube and set up TIs to do similar jobs to the built in ones (e.g. give a single user write access when they hit a "take control" TI)... this is fairly easy to do but could be daunting if you aren't that experienced.

If you can't do the above and really want to use an approval hierarchy applications model; you can as suggested split it into cubes for each year (which I'd hate to do)... OR concatenate your existing approval dim with the year dim; so for each element it would drill into "element a - year 1", "element a - year 2" etc... I still don't like that option but i'd marginally prefer it to splitting cubes. Either way you'd need a final reporting cube to combine all the results in a cube of your original structure.

[ChauBSD]

This is the biggest flaw of the contributor (applications) stuff in tm1; being able to have only 1 dim for your approval hierarchy renders it useless in a lot of cases.

In your position I would just build my own approval cube and set up TIs to do similar jobs to the built in ones (e.g. give a single user write access when they hit a "take control" TI)... this is fairly easy to do but could be daunting if you aren't that experienced.

Hi Declanr,

I don't have many experienced. But i wanna execute such as above way of your. Can you say more details problem. Why i build my own cube and how do setup TI.
Can you share me. I am try excute. I forced myself to perform.

Thank you

[declanr]

Hi Declanr,

I don't have many experienced. But i wanna execute such as above way of your. Can you say more details problem. Why i build my own cube and how do setup TI.
Can you share me. I am try excute. I forced myself to perform.

Thank you

I don't mean offence by this but having looked at your previous posts this method could take you down a road that will cause you more hassle than it's worth, like anything when set up well it will work perfectly... but with small omissions it will provide nothing but headaches. You should investigate the "responsibility" style of application as Overflow suggested or look into getting an experienced consultant to assist.


However the basic concept of setting up a cube is that instead of using the "TM1 Applications" screen (which only allow for an approval hierarchy on 1 dim) you would use TM1 Web (or possibly perspectives if desired) and have a cube to show the workflow; it would be a simple cube containing your 2 approval dimensions; the existing 1 PLUS the year dim, and will also contain a measures dimension (measures along the lines of "Active", "In Progress", "Submitted" and "Approved" as numeric... plus a "status" as string and some extra string for the users and timestamps etc.)... I'd also normally stick your version dim in here so you can see history of who approved what and when.

Your string "status" measure would simply be used to say that if "Approved" = "Active" (numerics) then status = approved, regardless of N or C... so on and so forth.

Someone starts off populating 1's in the "active" measure for those intersections that should be completed, this allows for it to ignore intersections which contain archived elements etc.


You have a TI that takes parameters from your approval dims and puts 1's in the relevant measures accordingly (after performing IF's to see if someone else has already done it etc)... you can put rules on the security cubes to state that when an intersection is "in progress" that user is the only 1 with "write" access; normally to do this you need to create user groups on the fly that contain only the user in question... e.g. "User A" would belong to "Workflow Group - User A" etc.

Stick some nice websheets in place to launch your action buttons and show your workflow and navigate around and then job done.


That's the basics of the concepts, i'd do quite a few things on top of that to "tidy" the model but there is little point in sharing that sort of stuff until the basics are covered.

Like I said before though; the above methodology isn't tricky by any means (which is why I'm confused as to why contributor/applications still doesn't allow for multiple approval dims in 1 app) but it would need to be built by someone who can:
A/ Foresee the sorts of problems that each line of TI could cause (and fix accordingly)
B/ Build it so that it will last for more than just 1 iteration
C/ Make it look nice; in my experience unless something looks fancy then it doesn't matter whether it is good or not because they won't use it (and if you've already shown your customers contributor; despite its flaws - it looks bloody nice and I must confess I am coming around to the way of thinking that it does simple 1 dimension approval models fairly well.)


If you wish to use something like contributor/applications the hard fact is that you need to design your cubes around that plan and quite often that requires a different sort of design to what would be most user-friendly/efficient in the other tm1 interfaces.
If you'd planned that from the start you could have designed your cubes in 2 sets, 1 designed for input (e.g. with your 2 approval dims concatenated into 1) and then another set of "reporting" cubes that take the output data and are designed nicely for users to do standard good ol' fashioned slicing/dicing analysis.