Child record list widgets should have NOT_PROTECTED permission rules by default

[KofTwentyTwo]

Problem

When an application sets restrictive default permission rules (e.g., READ_INSERT_EDIT_DELETE_PERMISSIONS with DenyBehavior.HIDDEN), child record list widgets created by ChildRecordListWidgetFromRecordEntityGenericMetaDataProducer get filtered out in MetaDataAction because they have null permission rules.

Root Cause

ChildRecordListRenderer.widgetMetaDataBuilder() creates a QWidgetMetaData but does not set permissionRules. When PermissionsHelper.getEffectivePermissionRules() is called for these widgets, it returns the instance's default permission rules (line 467):

if(metaDataWithPermissionRules.getPermissionRules() == null)
{
   LOG.warn("Null permission rules on meta data object...");
   return (instance.getDefaultPermissionRules());
}

If those default rules are restrictive and the user doesn't have the required permissions, the widget gets filtered out in MetaDataAction at line 180-184.

Suggested Fix

Set NOT_PROTECTED permission rules on child record list widgets by default in ChildRecordListRenderer.widgetMetaDataBuilder():

public static Builder widgetMetaDataBuilder(QJoinMetaData join)
{
   return (new Builder(new QWidgetMetaData()
      .withName(join.getName())
      .withIsCard(true)
      .withCodeReference(new QCodeReference(ChildRecordListRenderer.class))
      .withType(WidgetType.CHILD_RECORD_LIST.getType())
      .withDefaultValue("joinName", join.getName())
      .withValidatorPlugin(new ChildRecordListWidgetValidator())
      .withPermissionRules(new QPermissionRules().withLevel(PermissionLevel.NOT_PROTECTED))  // ADD THIS
   ));
}

This makes sense because:

1. Child record list widgets are displayed within a parent record's detail page
2. Access to the parent record already requires permissions on the parent table
3. The widget queries the child table, which has its own permission checks
4. The widget itself doesn't need additional permission gating

Workaround

Applications can work around this by adding a post-processor that sets permission rules on widgets with null rules:

qInstance.getWidgets().values().forEach(widget -> {
   if(widget.getPermissionRules() == null) {
      widget.setPermissionRules(new QPermissionRules()
         .withLevel(PermissionLevel.NOT_PROTECTED));
   }
});

Environment

• QQQ version: 0.40.0-SNAPSHOT

[darinkelkhoff]

re: "This makes sense because: 3 The widget queries the child table, which has its own permission checks" - i'd say that's inaccurate - as permissions are only applied on ingress points - e.g., one might not have the permission lineItem.read (e.g., direct query access to the line item table), yet an application may still want a lineItem child-list widget to be allowed, so, maybe no real "point" other than to clarify where permissions get applied.

and i guess i'd just disagree with 1 & 4 from that section, because there certainly could be use cases where you might want to hide some child data from some users. of course this proposed change doesn't negate that capability, but again, i'm just saying that i disagree with the assertion that "the widget itself doesn't need [permissions]".

re: an alternative approach for this - it seems like the whole "defaultPermissionRules" object in QInstance isn't too useful, and maybe building something more robust to take the place of that would be better... off the top of my head i could see something like an "ApplyDefaultPermissionsInterface" that we could add to a QInstance (via a CodeReference), which would take in a MetaDataWithPermissionRules - where an implementation could then switch on the type of object, and for this specific use case, then do a secondary switch on the widgetType, and if it's CHILD_RECORD_LIST, then apply this rule? 🤷

as a final comment, the workaround - rather than doing that quite so "ad hoc" as shown here, the more idiomatic way i'd say for doing something like that would be with an "Enricher Plugin" - which can be auto-discovered via QInstanceEnricher.discoverAndAddPluginsInPackage - or manually added to the enrichment process w/ addEnricherPlugin.

As another alternative, i know we tend to not love static attributes, but maybe ChildWidgetRenderer.Builder.DEFAULT_PERMISSION_LEVEL could be added, and that could be used on the "// ADD THIS" line (then we'd get to debate the default for that default (null vs NOT_PROTECTED).