Change server response for enumerable-but-not-selectable columns

[karlcz]

A pain point for configuring complex policies is that you can end up with columns which have enumerate but not select privileges for a certain class of user. There are currently two different behaviors of the underlying ermrest APIs depending on how the privileges are determined

• Static determination yields 401/403 errors on attempted access to the column
• Dynamic determination yields rows with null values for the non-selectable column

This occurs for both explicit column use by /attribute/ and /attributegroup/ APIs and for implicit column use by the /entity/ API.

It is proposed that we modify the service response to unify these scenarios. Rather than returning errors, always return the column with null regardless of whether dynamic access control bindings are in play.

@hongsudt @ljpearlman

[karlcz]

This proposal seems to intersect with the existing issue #237 where we see other effects from the evaluation of static policies. How would we want these join scenarios to work?

If we consistently handle non-selectable columns as producing null results, then these joins would no longer raise 409 or 401/403 errors. Instead, they would be evaluated using the nulls and so either produce empty result sets (inner joins) or unmatched rows (outer joins).

There may also be interesting performance implications for joins on large tables. A straightforward implementation of the new behavior will replace table instances with subqueries producing the nulled content. (This is how we already handle tables with columns masked by dynamic acl bindings.) It isn't always clear how efficiently the postgres query planner will handle these subquery scenarios.