TeamDesk Knowledge Base & Support

Home

FAQ

Forum

Idea Exchange

Ask a Question

My Stuff

Help

Column access breaking change

Currently column access is controlled by "Access" property of particular column. If you set it to "No Access" for particular role, then nobody in that role can access the column. If such column is used in formulas, summaries or lookups, these columns are also become unavailable for that role automatically regardless of "Access" property of affected column. You may override that behavior by using "Override access right" option for particular formula, summary or lookup column. More problems arise if such column with "No Access" is used in relation – a whole relation with all lookups and summaries will be unavailable. Sometimes finding the reason why you don't see these depending columns or got "no access" error in view can be quite cumbersome task.

We want to simplify that by changing column access behavior to control availability of particular column ONLY. So, when you set column access to "No Access", only that particular column will not be available, but formulas, lookups or summaries where it's used will not be affected. Relations where it used will not be affected also.

The drawback of that change is if you rely on current "automatic" logic – you'll need to change access for dependent columns manually.

We'll be happy to hear any feedback on what you think about that possible change.

ID
608

Category
TeamDesk

Author

Slava Shinderov Staff

Date Created
3/21/2013 6:54:11 AM

Date Updated
5/14/2013 7:03:01 AM

Status
Implemented

Score
50

Promoted By

	Rick Cogley		martin oliver		basenine
	Liquid Rapid		Slava Shinderov Staff

Comments

	Liquid Rapid 3/21/2013 7:42:30 AM Hi Slava, Interesting you bring this up now, as I was just pondering how to explain this to someone so they don't accidentally break things I've built for them. It's pretty common in more complex functionalities I build for long chains of relations and columns to exist. A lot of times several functionalities in different places in the application will all build out from the same set of core columns. If you restrict access to just one of those core columns, the effect of that can actually snake out in all directions and break several things in several different places in the app. It makes it necessary to be very careful in configuring column access restrictions. I actually avoid column access restrictions as much as possible because of this. There are so many implications to think through for every restriction you configure. I try to use form behavior and careful view configuration instead, wherever possible. There are benefits to the current model, if you develop specifically for it. If you want a set of formula columns that are all derived from one column, ie various details derived from a date, you can use this to control access to all the columns in one place. Just flip around access restrictions on the one date column, and you're controlling access to all of the derived data. But I suspect that's not a very common thing to do. I don't think I've built anything that depends on that behavior. I think the benefits of the suggested change outweigh the benefits of the current model. It prevents inadvertently breaking things with column access restrictions. That makes a lot of things in my apps less fragile. And I think it's more intuitive for users who do their own development: I configure access restrictions here, they apply here and nowhere else. They don't break something unexpectedly 3 tables away. If I want access restrictions on any formula columns derived from this column, then I configure them on those columns explicitly. Much simpler to keep your head around, and more robust. I support the change.
	basenine 3/21/2013 6:34:03 PM I agree with Nathan. Currently, the best way to avoid "no access" is to use the 'Form Behaviour' for a role. I find it the easiest and most practical way to secure the application for specific access rights.
	basenine 3/26/2013 6:25:13 PM Would it be possible to have a Checkbox to toggle between the new model and the current model? So when you create a column that requires restrictions, you can either "set it for all cascading" or switch it to "just this column"...
	martin oliver 3/27/2013 12:24:02 PM I support the either or option with a toggle option
	Slava Shinderov Staff 5/14/2013 7:03:01 AM We've changed column access behavior to affect availability of particular column ONLY. So, when you set column access to "No Access", only that particular column will not be available, but formulas, lookups or summaries where it's used won't be affected. Relations where it's used will not be affected as well. If your application is not compatible with that change, please disable it in Labs.

Feedback

Back to Search Results