HPT Implementation:web form based security is not sufficient...

I've just come across an instance in a hyperion planning system 9.3.1 implementaion where a few accounts were set to read only by using a row definition setting in a planning web form. Having this feature available to us as developers sounds pretty handy until you think about the consequences. This will lock down the cell for web forms and smartview if used in the web form mode. If however your users will have access to smartview adhoc (if they have smartview they have this) or the excel addin with "essbase write" access provisioned to them, this cell is wide open for users to change the values.

Why might you want a cell to be read only? You could have a business rule that populates the value based on drivers or some other metric, this account could be pre-seeded, or only admin personnel should be able to update this account.

What are some workarounds that are a better best practice?
-in planning under dimensions, give all users read access only to this specific account. (have a group created for all users, preferably 2 groups, all users read and all users write)
-in essbase / planning, make a new account that is a dynamic calc that merely points to this member. By having the property set to dynamic calc, planning will automatically set the cell to read only.

This is similar to a project (large datawarehouse) where everyone thought that securing access to specific web analysis forms and financial reporting reports would limit users access to the entire essbase cube data. While they did not allow access to the excel addin, they did allow users to create their own web analysis reports. I mentioned that while our 85 security filters did limit access to data based on the entitiy dimension it did not eliminate the users from seeing the data that made up these reports. The customer was just overwhelmed with the project and said it was good enough.

hj