RFE 85099: Toggle for Read-Only Mode in Perspectives

Suggest and discuss enhancements for TM1
Post Reply
User avatar
mattgoff
MVP
Posts: 516
Joined: Fri May 16, 2008 1:37 pm
OLAP Product: TM1
Version: 10.2.2.6
Excel Version: O365
Location: Florida, USA

RFE 85099: Toggle for Read-Only Mode in Perspectives

Post by mattgoff »

http://www.ibm.com/developerworks/rfe/e ... R_ID=85099

It's not uncommon for users to make inadvertent changes to data in TM1, particularly if they're making use of the DBS statement. Best method is to enclose DBS in an IF statement, but even if this is done (it often is not) users sometimes inadvertently save a file with the DBS activated and upload when opening an old file.

This situation could be mitigated if Perspectives had a toggle to place the system into a read-only mode in which all writes (or at least DBS statements) were deactivated.

This would also be helpful if a user sends a file to another user or admin, for example to help debug an error. The only way for the receiving user to safely open the file w/o risk to changing data in TM1 is to log out of TM1, open and inspect the file, then re-login to TM1. This is a cumbersome process and often not done despite the risk.
Please read and follow the Request for Assistance Guidelines. It helps us answer your question and saves everyone a lot of time.
User avatar
gtonkin
MVP
Posts: 1192
Joined: Thu May 06, 2010 3:03 pm
OLAP Product: TM1
Version: Latest and greatest
Excel Version: Office 365 64-bit
Location: JHB, South Africa
Contact:

Re: RFE 85099: Toggle for Read-Only Mode in Perspectives

Post by gtonkin »

Would you not be better off removing the reliance on users to a custodian and have this built in to your scenario control?

You could rather build cell security rules to add this layer - overall read-only, group read-only etc. This way the model is read-only where and when it needs to be?
Also, the issue with having the session to all active servers read-only may not suit users as they may be contributing to one model but reviewing on another.
User avatar
mattgoff
MVP
Posts: 516
Joined: Fri May 16, 2008 1:37 pm
OLAP Product: TM1
Version: 10.2.2.6
Excel Version: O365
Location: Florida, USA

Re: RFE 85099: Toggle for Read-Only Mode in Perspectives

Post by mattgoff »

gtonkin wrote:Would you not be better off removing the reliance on users to a custodian and have this built in to your scenario control?

You could rather build cell security rules to add this layer - overall read-only, group read-only etc. This way the model is read-only where and when it needs to be?
Also, the issue with having the session to all active servers read-only may not suit users as they may be contributing to one model but reviewing on another.
We do this. We have a single "forecast" version with rules feeding in actuals (based on a "first open period" cell in a control cube). We snapshot off this version each month when forecast is due. All versions except "forecast" are read only, and obv actuals are read-only in "forecast" since they're rule-supplied.

The issue we've had is in the forecast periods in our forecast version. Let's say a user uses a template in January to upload forecast for the rest of the year, and the user inadvertently saves that template with the DBSes active. Two months later, they reopen the old file to look up a formula, cell comment, whatever, and ...poof... the values are immediately re-uploaded. The values which are now actual (Jan and Feb) are safe, since those are now read-only, but the remainder of the forecast is inadvertently altered.

Or, imagine a user with read-only access sends a file to a user with read-write access (e.g. they're in training, want some feedback on an analysis, whatever) and inadvertently have DBSes active. The sending user might not know or care that DBSes are active, since, given their access, it doesn't affect anything. The receiving user might not even notice the active DBSes, e.g. if it's on another tab, but data could be altered under their account credentials.

Agree that a single control to affect all models is not very granular, but it also simplifies the behavior and interface.

Matt
Please read and follow the Request for Assistance Guidelines. It helps us answer your question and saves everyone a lot of time.
User avatar
gtonkin
MVP
Posts: 1192
Joined: Thu May 06, 2010 3:03 pm
OLAP Product: TM1
Version: Latest and greatest
Excel Version: Office 365 64-bit
Location: JHB, South Africa
Contact:

Re: RFE 85099: Toggle for Read-Only Mode in Perspectives

Post by gtonkin »

If the user opens the template whilst in Write mode, you are still not any better off as they would have still inadvertently updated with data in the template.

You are trying to put "a cork on a fork" - I have seen this too many times - just trying to think of an elegant solution to address.

Would be great if TM1 could intercept the first send and ask if you are sure you want to send data, similar to an Action Button but this would obviously be tricky as you probably want the response to persist for a duration, the session etc. so that they do not get bombarded with message boxes and just click Yes everytime thereby put you back to square one.

We generally also create a dimension with elements relating to the templates and attributes relating to versions. Validation can then be don to ensure older templates are never used but this does not alleviate the issue if they open yesterday's template.

Setting calculation to manual in the workbook open won't help either if TM1Rebuild is set to 1. The add-in takes precendence.

Anyway, just throwing out ideas as I think the suggestion is great but the solution needs to be practical and ID10T proof.

Any other gurus out there with thoughts and ideas?
User avatar
mattgoff
MVP
Posts: 516
Joined: Fri May 16, 2008 1:37 pm
OLAP Product: TM1
Version: 10.2.2.6
Excel Version: O365
Location: Florida, USA

Re: RFE 85099: Toggle for Read-Only Mode in Perspectives

Post by mattgoff »

I agree, an "upload/activate DBSes for session" button would be a better solution, particularly because it eliminates the need to the user to remember to disable upload in advance.
Please read and follow the Request for Assistance Guidelines. It helps us answer your question and saves everyone a lot of time.
User avatar
Steve Rowe
Site Admin
Posts: 2410
Joined: Wed May 14, 2008 4:25 pm
OLAP Product: TM1
Version: TM1 v6,v7,v8,v9,v10,v11+PAW
Excel Version: Nearly all of them

Re: RFE 85099: Toggle for Read-Only Mode in Perspectives

Post by Steve Rowe »

I think this problem can be looked at a different way.

DBS are by design an extremely simple method of getting data into TM1, the downside of them being simple to implement is that they are difficult to control and prone to false transmission of data. This has been made worse by additions to the TM1 client that further weaken the control, i.e. TM1Rebuild=1.

Most of the issues listed above I think can be covered off by a few lines of VBA in the auto open code, though I appreciate that may not be allowed everywhere. In addition your security model and use of locking should be managing this issue as well.

IMO the real answer is don't use them and consider flat file export and TI load instead if you want push button data loads.

If DBS already had some kind of global session on / off switch, I bet we would have people saying I wish we could set the DBS up so it was always on as people keep failing to transmit data to the system.
Technical Director
www.infocat.co.uk
User avatar
mattgoff
MVP
Posts: 516
Joined: Fri May 16, 2008 1:37 pm
OLAP Product: TM1
Version: 10.2.2.6
Excel Version: O365
Location: Florida, USA

Re: RFE 85099: Toggle for Read-Only Mode in Perspectives

Post by mattgoff »

I'm not sure I agree. It sounds like you're saying "DBS is simple and works great except for this one usability flaw... so don't use DBSes." Why not fix the usability flaw?

Although the majority of my users are Excel wizards, AFAIK none use VBA. Anything involving TI means a TM1 admin has to be involved, and that's counter to the self-sufficiency that makes TM1 so much better than the alternatives. As I described earlier, security can't solve the issue as the cells which are being inadvertently changed need to stay writeable.

I think gtonkin's suggestion of adding a "upload DBSes" button fits in well with existing active form UX. It's also very similar to autocalc vs. recalc button in the cube viewer. These are both situations where an automatic setting is problematic (generally for time reasons) so there's an on-demand button (and an auto/manual toggle for the latter).
Please read and follow the Request for Assistance Guidelines. It helps us answer your question and saves everyone a lot of time.
User avatar
Steve Rowe
Site Admin
Posts: 2410
Joined: Wed May 14, 2008 4:25 pm
OLAP Product: TM1
Version: TM1 v6,v7,v8,v9,v10,v11+PAW
Excel Version: Nearly all of them

Re: RFE 85099: Toggle for Read-Only Mode in Perspectives

Post by Steve Rowe »

Yeah, I can see the logic that leads to this enhancement and it would be good to have a greater level of control in the vanilla client so that end-users can manage their behaviour without admin level help.

It needs to be implemented with care though, so that it doesn't interfere too much with those that are happy (ish) with the current behaviour. It should be obvious if you are in submit mode or not and with defaults stored in the client ini file and so forth.

If you were not in commit mode, what happens if you execute a DBS? Obviously nothing makes it to the TM1 instance but does the user get any kind of message that their DBS has failed (as this may not have been the intention). I think a dialogue box might be overkill and annoying but something in the status bar that indicates a failed DBS attempt would be good.

We would need to be sure we didn't create a new usability problem in solving the original one.
Technical Director
www.infocat.co.uk
Post Reply