## Summary
- Add support for virtual fields (`QVirtualFieldMetaData`) across the customizable table views qbit
- The table personalizer now filters virtual fields based on the user's table view, similar to regular fields but without "always keep" rules
- Virtual fields are included in the field possible value source (for search and lookup), allowing them to be added to table views
- `FieldAccessLevel.validateForField` treats virtual fields as read-only, preventing them from being assigned editable access levels
- `TableViewFieldCustomizer` resolves virtual fields via `getFieldOrVirtualField` so they can be validated during insert/update
## Test plan
- [x] `FieldAccessLevelTest.testValidateForVirtualField` — virtual fields (editable or not) only accept `READ_ONLY`
- [x] `TableViewFieldCustomizerTest.testVirtualField` — virtual fields resolve and validate correctly
- [x] `CustomizableTableFieldPVSTest.testWithVirtualFields` — virtual fields appear in PVS search/lookup, hidden ones excluded
- [x] `CustomizableTableViewsTablePersonalizerTest.testApplyViewToTableWithVirtualFields` — virtual fields filtered by view; empty view keeps none; null virtual fields handled
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Possible NPE: table.getVirtualFields() can be null for tables without virtual fields, so this line will throw instead of returning null for unknown ids (e.g., "tableName.doesNotExist"). Please null-check before .get(fieldName).
Possible NPE: `table.getVirtualFields()` can be null for tables without virtual fields, so this line will throw instead of returning null for unknown ids (e.g., `"tableName.doesNotExist"`). Please null-check before `.get(fieldName)`.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Summary
QVirtualFieldMetaData) across the customizable table views qbitFieldAccessLevel.validateForFieldtreats virtual fields as read-only, preventing them from being assigned editable access levelsTableViewFieldCustomizerresolves virtual fields viagetFieldOrVirtualFieldso they can be validated during insert/updateTest plan
FieldAccessLevelTest.testValidateForVirtualField— virtual fields (editable or not) only acceptREAD_ONLYTableViewFieldCustomizerTest.testVirtualField— virtual fields resolve and validate correctlyCustomizableTableFieldPVSTest.testWithVirtualFields— virtual fields appear in PVS search/lookup, hidden ones excludedCustomizableTableViewsTablePersonalizerTest.testApplyViewToTableWithVirtualFields— virtual fields filtered by view; empty view keeps none; null virtual fields handled🤖 Generated with Claude Code
@@ -96,6 +96,12 @@ public class CustomizableTableFieldPVS implements QCustomPossibleValueProvider<S{Possible NPE:
table.getVirtualFields()can be null for tables without virtual fields, so this line will throw instead of returning null for unknown ids (e.g.,"tableName.doesNotExist"). Please null-check before.get(fieldName).