Whenever dimensions and their values are accessed, they should by default only show public dimensions.
For private dimensions, there should be a includePrivate: true or similar mechanism to ask for private dimension to be included. Private dimensions should be filtered using CBAC (#324) when asked for.
DBAC should allow event admins to share a number of private dimensions with volunteers matching a set of dimensions such as the example below.
Finally, we should design which UI is it that will convey the dimensions thus exposed to the recipients. For example, the Program Guide V2 Light, when logged in, could include a switch to also display private dimensions (if any are available to the users) and it could then be used to filter the view and export.
Example
For Ropecon 2025 volunteers with these dimensions
state: accepted
job-category: photographer
grant a CBAC entry with the following claims
event: ropecon2025
app: program
dimension: photo-permission
with validity until 3 months after the end of the event.
Open questions
The fate of cachedDimensions
Should we add the includePrivate (and listFilterOnly, detailOnly) parameter in cachedDimensions, too?
The program guide is accessed fairly often, so would prefer to keep fields used by it as fast as possible. In order to check which dimensions should be retained when resolving cachedDimensions, one would have to query all dimensions of the event. This speaks against offering filters on cachedDimensions: users who are special can always use dimensions instead.
Another option would be to have two underlying database fields: cachedPublicDimensions and cachedAllDimensions, and use includePrivate to toggle which is used to resolve cachedDimensions. This would double the raw storage needed for cachedDimensions in the database; then again, the description field is often long enough so that the row exceeds TOAST threshold and becomes eligible for compression, so actual storage expansion might be less than that.
Whenever dimensions and their values are accessed, they should by default only show public dimensions.
For private dimensions, there should be a
includePrivate: trueor similar mechanism to ask for private dimension to be included. Private dimensions should be filtered using CBAC (#324) when asked for.DBAC should allow event admins to share a number of private dimensions with volunteers matching a set of dimensions such as the example below.
Finally, we should design which UI is it that will convey the dimensions thus exposed to the recipients. For example, the Program Guide V2 Light, when logged in, could include a switch to also display private dimensions (if any are available to the users) and it could then be used to filter the view and export.
Example
For Ropecon 2025 volunteers with these dimensions
grant a CBAC entry with the following claims
with validity until 3 months after the end of the event.
Open questions
The fate of
cachedDimensionsShould we add the
includePrivate(andlistFilterOnly,detailOnly) parameter incachedDimensions, too?The program guide is accessed fairly often, so would prefer to keep fields used by it as fast as possible. In order to check which dimensions should be retained when resolving
cachedDimensions, one would have to query all dimensions of the event. This speaks against offering filters oncachedDimensions: users who are special can always usedimensionsinstead.Another option would be to have two underlying database fields:
cachedPublicDimensionsandcachedAllDimensions, and useincludePrivateto toggle which is used to resolvecachedDimensions. This would double the raw storage needed forcachedDimensionsin the database; then again, thedescriptionfield is often long enough so that the row exceeds TOAST threshold and becomes eligible for compression, so actual storage expansion might be less than that.