TM1 Forum

Hello All,

I provided Action button to users to run the TI process to update the data. When user (Who has consolidation access)executes data is getting updated but TI process says it failed. When as a admin i run it than it runs successfully.I assign all internal and master process 'READ' security for test group. What else we need to take int o consideration to make it successfull.

Thanks

Dharav

dharav wrote: I provided Action button to users to run the TI process to update the data. When user (Who has consolidation access)executes data is getting updated but TI process says it failed. When as a admin i run it than it runs successfully.I assign all internal and master process 'READ' security for test group. What else we need to take int o consideration to make it successfull.

Request For Assistance Guidelines wrote: 4) Similarly if you're getting unexpected results, specifics of what you're running, how, and what results you're getting will yield a more valuable response than "I'm running a T.I. but my code doesn't work properly". If you're getting an error, please be specific about what the error is (full details, not just "a runtime error" or "process terminated with errors"), and the circumstances under which it's occurring. But remember that even if you do specify the exact error message, it's not likely to be helpful unless you provide the context for it; which part of the software the error is occurring in (point 2 above), and what, specifically, you were doing at the time.

5) For Rules and TurboIntegrator processes, posting the actual code and the real names of and structures of your cubes, dimensions and elements will be a thousand times more useful than an attempted description of them. You don't need to post real data, but the real code is needed.

The code that is being executed in the process is... what?

The tm1 server log (not the transaction log, the server log) gives the reason for failure as... what?

As Alan has highlighted the code and error log details will allow people to provide the definitive answer but hazarding a guess based on the little you have stated I would speculate that the TI performs a security function (e.g. Security Refresh) and you haven't got the "Security Access" box ticked for the TI; if that is the case note that the Security Access check box is not the same as a user have access to run the TI.

declanr wrote:As Alan has highlighted the code and error log details will allow people to provide the definitive answer but hazarding a guess based on the little you have stated I would speculate that the TI performs a security function (e.g. Security Refresh) and you haven't got the "Security Access" box ticked for the TI; if that is the case note that the Security Access check box is not the same as a user have access to run the TI.

Actually that thought crossed my mind too, but that doesn't account for it running correctly when he runs it as Admin. The Security Access checkbox, yet another utterly time wasting pain in the backside obstruction[1], will screw you just as effectively if an admin runs the process as when a non-admin does. As indeed I find from bitter experience every time I forget to check that particular waste of space.

Given that as an admin I am highly discriminating about what I let users run, I would much rather that the default position for TI processes be "Do what I damn well tell you to do, and if I want you NOT to do something (like affecting security), then I'll let you know by NOT telling you to do that."

-----------------
[1] Though this is one that I don't blame so much on IBM, but rather on the "seen to be doing something after the horse has bolted" mentality that reached its nadir in the Sarbanes-Oxley legislation (exhibit 1 in the case of R vs We Don't Need More Laws, Just For The Ones We Have To Be Enforced) and the creation of the DataAdmin and SecurityAdmin groups. I probably wouldn't have cared had there been a checkbox to turn security access OFF rather than needing to turn it on - that way I could ignore it just as I ignore the aforementioned security groups - but of course that wouldn't have maintained the false sense of security charade quite as effectively. And yet oddly IBM still hasn't implemented forced periodic password changes in standard security, the one myth of security enhancement that seems to be almost universally bought into by those who don't know any better, and one which therefore causes us no end of problems with auditing departments. Go figure.

Alan Kirk wrote: Actually that thought crossed my mind too, but that doesn't account for it running correctly when he runs it as Admin. The Security Access checkbox, yet another utterly time wasting pain in the backside obstruction[1], will screw you just as effectively if an admin runs the process as when a non-admin does. As indeed I find from bitter experience every time I forget to check that particular waste of space.

When running a TI as admin you don't need to check the box and all security functions are actioned correctly; the box is just so that the TI treats a standard user as if they were something like an admin. Processes ran by chore are also subject to the tick box.

I agree with the whole concept of get rid/change though; if a user is given access to run a process then you hope the person giving access wanted them to run it and not something a bit like it that does most of what it does but not quite.
Also find very annoying the fact that changing a tiny bit of code in said TI will untick the box without warning you...

declanr wrote:

Alan Kirk wrote: Actually that thought crossed my mind too, but that doesn't account for it running correctly when he runs it as Admin. The Security Access checkbox, yet another utterly time wasting pain in the backside obstruction[1], will screw you just as effectively if an admin runs the process as when a non-admin does. As indeed I find from bitter experience every time I forget to check that particular waste of space.

When running a TI as admin you don't need to check the box and all security functions are actioned correctly; the box is just so that the TI treats a standard user as if they were something like an admin.

You are quite correct, good sir, that is indeed the behaviour in 10.2.2, which is the only version that I have my hands on at the moment. (My lovely company-supplied Lenovo with our production 9.5.2 software having decided that it no longer wishes to respond to the On button but would rather deposit tiny glass beads over my desk. No, I have no idea either, for it has not been dropped or otherwise mistreated.

declanr wrote:Processes ran by chore are also subject to the tick box.

And you are also correct here, for I recall two things about the one that caught me out:
(a) It was part of a chore (something that I concede had not crossed my mind until you raised it); and
(b) I was mightily, mightily p*ssed that I got an error process when I ran the chore as Admin.

And I must emphasise that last point; scheduled chores run as Data Admin (as I recall you pointing out in a thread from some months ago), so the fact that they get the error is unsurprising. Annoying as h3ll when you forget that they no longer run with Admin rights, but unsurprising.

But I actually triggered the chore myself, and got the error.

However that is not happening in 10.2.2; me triggering the chore runs it correctly. And I cannot recall whether it happened in a production or test environment, meaning that it could well have been a version / fixpack specific issue. But I do remember it very clearly, for as one has doubtless noted from my previous comments in this thread I find this "feature" to have little utility beyond annoying the crud out of admins.

declanr wrote:I agree with the whole concept of get rid/change though; if a user is given access to run a process then you hope the person giving access wanted them to run it and not something a bit like it that does most of what it does but not quite.
Also find very annoying the fact that changing a tiny bit of code in said TI will untick the box without warning you...

Wow. I haven't encountered that at least. What was the magnitude of the change? I just added a CellPutN to a test security process and the box stayed on... but again this may be specifically in 10.2.2.

Alan Kirk wrote:

declanr wrote:I agree with the whole concept of get rid/change though; if a user is given access to run a process then you hope the person giving access wanted them to run it and not something a bit like it that does most of what it does but not quite.
Also find very annoying the fact that changing a tiny bit of code in said TI will untick the box without warning you...

Wow. I haven't encountered that at least. What was the magnitude of the change? I just added a CellPutN to a test security process and the box stayed on... but again this may be specifically in 10.2.2.

I have just tested this and it appears I was lying... I was so sure that this used to happen but it certainly isn't in 10.2.2 any-more; maybe it was just the other developers screwing with me over a course of years.

declanr wrote:

Alan Kirk wrote:

declanr wrote:I agree with the whole concept of get rid/change though; if a user is given access to run a process then you hope the person giving access wanted them to run it and not something a bit like it that does most of what it does but not quite.
Also find very annoying the fact that changing a tiny bit of code in said TI will untick the box without warning you...

Wow. I haven't encountered that at least. What was the magnitude of the change? I just added a CellPutN to a test security process and the box stayed on... but again this may be specifically in 10.2.2.

I have just tested this and it appears I was lying... I was so sure that this used to happen but it certainly isn't in 10.2.2 any-more; maybe it was just the other developers screwing with me over a course of years.

Lying has never struck me as being your style.

Random irritating bugs in fix packs has always struck me as being Iboglix's, though.

Hello Alan Kirk & Declanr

Thanks for your response and sorry as i did not provide TI processes. I have 16 TI processes and i simply execute them in a master process with Execute Process TI function.

Security Access has been checked. In log file, I came to know that

=> Process is failing because user has the right of New Jersey Metro only and due to which it can not update New York data. I have created all processes at Region Node (top level) for all child elements (metros). Admin has top level access so it goes through successfully. I presumed that TI process won't

=> Second, Prolog procedure line (63) cell is not writable. Where line 63 is ViewZeroOut(vCube,vView); According to me, As user don't have access to other metro, it won't allow to zero out those metro.

Overall, process are getting failed as user does not have rights of another metro. Basic TI structure,

=> To, get data from the cube for all metros for Version 'Actual' in a text file
=> To ZeroOut Version='Actual 2015' for all metros
=> To upload data from text file to 'Actual 2015' based on 3 key values. If 3 key values are getting matched than sum it up the data for all metros.

" How would we assign the parameter for metro so that based on user workflow process automatically gets the metro name."

Please feel free if you require further information.

Thank You

Dharav