Codeer.LowCode.Blazor 1.3.19

• net8.0

  • Codeer.LowCode.Blazor.Licensing (>= 1.3.0)
  • Microsoft.AspNetCore.Components.WebAssembly (>= 8.0.4)
  • Microsoft.AspNetCore.Http.Abstractions (>= 2.1.1)
  • Microsoft.AspNetCore.WebUtilities (>= 8.0.4)
  • Microsoft.CodeAnalysis.CSharp (>= 4.9.2)

- PermissionField: row-dependent write conditions are now verified on the server with an SQL exists check instead of an in-memory re-evaluation. Conditions that reference linked-module values (dotted link fields) or 1:N list fields (exists over child rows) now work in field-level permissions; previously such conditions were always denied on save.
- Match conditions: the in-memory evaluation used for client-side display now follows loaded 1:N list data with the same exists semantics as the SQL evaluation. AND conditions that target the same list field are combined so that a single child row must satisfy all of them, keeping the client-side read-only display consistent with the server-side decision.
- Design check: condition variables that reach into an embedded 1:N list field (e.g. "Members.Status.Value") are now resolved through the list's linked module instead of being reported as missing, matching how the SQL and in-memory evaluations treat them.
- List fields on linked modules can now be used in conditions ("link-hop list reference"). A path such as "Department.Members.User.Value" reaches through a link field into a list field defined on the linked module and is evaluated as an exists condition, with the same semantics as a list field on the module itself (search conditions, row-level permissions, PermissionField conditions, bare Exists/NotExists, and same-row combination of AND-connected conditions). DataOnlyFields accepts the same dotted path to embed the linked list rows into the response so client-side permission display matches the server decision. Design check, in-memory evaluation, and read protection follow the same path rules.
- Fixed: negated condition groups (NOT on a nested AND/OR group) lost their negation when the SQL was generated, making the SQL filter more permissive than designed while the client-side evaluation negated correctly. Negated groups are now kept as boundaries during condition flattening.
- Fixed: when AND-connected conditions on the same list field were split across nested condition groups, the SQL evaluation combined them into a single exists (same child row must satisfy all) while the in-memory evaluation treated each nesting level separately. Both now combine over the flattened AND chain.
- Link-hop lists can now be displayed: placing a dotted path such as "Department.Members" on a detail layout renders the linked module's list read-only. The rows come from the same server-side embedding as DataOnlyFields (a snapshot at load time; the client never re-queries with the wrong binding), the link FK needed for embedding is added to the select list automatically, and displayed columns follow the list module's list layout. A dotted-named list field is always resolved as a link-hop list in conditions and embedding, so the display clone never changes condition semantics.
- Fixed: dotted link paths placed directly on detail or search layouts were not collected when the design was loaded (the layout entry was silently removed unless the dotted column was also declared as a field or used in a condition). List layouts were unaffected.
- Scalar fields on linked modules can now be used in conditions without declaring a dotted link column. Paths such as "Department.Manager.Value" used in row-level conditions (DataRead/DataWrite), PermissionField conditions, or DataOnlyFields are resolved automatically when the design is loaded, with the same semantics as a declared dotted link column (LEFT JOIN; null for unlinked rows). Dynamic search conditions still require the dotted column to be placed on a layout.
- Code-defined design enums: a C# enum marked with the new DesignEnum attribute is published as a design enum without an enum definition file (usable from SelectField.EnumName, condition editor value candidates, and scripts). Save values follow the design-enum rules (String: member name, overridable per member; Number: the underlying numeric value), display texts support "$key" resource localization resolved from the defining assembly, and the synthesized enums are merged at design load time and never written to design files. Intended for custom field libraries to ship their vocabulary (status values etc.) with a single definition in code. A ToDesignValue() extension method returns the stored value of an enum member for C# code that compares against database values.
- Breaking change: the same-name equivalence between a design enum and a script-exposed C# enum (introduced in 1.3.15) has been removed. A design enum whose name matches a script-exposed C# enum is now reported as a duplicate name by the design check, like any other name collision, and scripts no longer resolve such a name specially (identifiers follow the normal resolution order, so the script-exposed C# enum wins and any value mismatch surfaces as an ordinary conversion or validation failure). Define the enum once in C# with the DesignEnum attribute instead; the separate design-enum definition and the equivalence rule are no longer needed.