TM1 Forum

Hello TM1-Community,

i need the same user to have WRITE permissions while using TM1 Web and only have READ permissions while using Perspectives (building his own reporting without editing values accidentally).
I thopught about different possibilities:
1. Give him two users and tell him to use one in Web and the other one for perspecitves -> not very secure
2. Rebuild a reporting-cube/insert new "reporting elements" and use rules + element security -> more RAM usage
3. Get Client-Type (Web/Perspectives) and use ReadOnlyUser in }ClientProperties with Chore/Rule -> Problem: Client type is visible in Tm1Top but not in TM1 itself

Does anyone have another idea or knows how to get the client type?

Ty

Why not just give the person access to your development environment for report building and then they can publish to production when ready?

Not a bad ideae but they want to build it ad-hoc with productive data and use it in excel not in tm1 web

McSash wrote:Not a bad ideae but they want to build it ad-hoc with productive data and use it in excel not in tm1 web

So what's actually the issue with building a report on productive data? What does it matter that the user building the report might have write access to the cube?

Hi

By a reporting cube I guess you mean create another cube with the same dimensions and rule the data across so that they build on that instead of the real cube. That could work, and if they don't need zero suppression then you don't need to feed. However, there is still nothing that will stop them writing data to the main cube by accident. It just lessens the risk.

In some cases I deliberately give advanced users a link to the underlying cube instead of a web sheet as they know enough to configure the view they want to make their data entry easier than it would be through the web sheet.

In the worst case scenario that they do accidentally change some data, remember that you always have the transaction log and can roll back their changes to the previous values. If they are accountants and they are reporting from it, they will probably reconcile everything and know that they have changed the values accidentally.

We also have various checks, eg does the balance sheet balance, etc.

In normal use I tend to make the whole cube read only once the month end is finished, so if they only develop reports at this time, it should be OK.

Other options like two user ids are still not going to stop accidents completely, and they could have license cost implications.

The other option is the Dev environment option, which can work, although they could accidentally destroy some test data that you set up. Even then there is still nothing to stop them pointing Perspectives at Production and working directly there. We do this with some users who update complex mappings, and then use a mechanism I built to promote these to production.

Personally I like the security model in TM1, where security is embedded in the cubes and it doesn't matter how you access it, you get the same rights. This is better than most other systems were security has to be built into each application that accesses the database, which adds a considerable overhead and leads to inconsistency.

At most sites the super users can access the cubes directly through Perspectives or TM1 Web Views. In all cases this has been a great benefit. The very few times that something gets changed accidentally, a quick roll back has sorted that out. The bigger issue is normally accidental spreading, but thankfully we can finally turn off type-in spreading in the later versions.

Regards

Paul Simon