Nathan Phillips (CW) 3/21/2013 7:42:30 AM
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.