Show custom fields per default in member overview closes #197 and #153 #208

Merged
carla merged 8 commits from feature/197_custom_fields_overview into main 2025-12-01 10:05:31 +01:00
Owner

Description of the implemented changes

The changes were:

  • Bugfixing
  • New Feature
  • Breaking Change
  • Refactoring

We want to show the custom fields as columns in the member overview. For now by default with a flag set to true.

What has been changed?

  • a flag show_in_overview has been added to custom fields via migration (default: true)
  • table component has been enhanced by a list of custom fields that is rendered as columns
  • The member live view passes custom fields to the table

Definition of Done

Code Quality

  • No new technical depths
  • Linting passed
  • Documentation is added were needed

Accessibility

  • New elements are properly defined with html-tags
  • Colour contrast follows WCAG criteria
  • Aria labels are added when needed
  • Everything is accessible by keyboard
  • Tab-Order is comprehensible
  • All interactive elements have a visible focus

Testing

  • Tests for new code are written
  • All tests pass
  • axe-core dev tools show no critical or major issues

Additional Notes

## Description of the implemented changes The changes were: - [ ] Bugfixing - [X] New Feature - [ ] Breaking Change - [ ] Refactoring We want to show the custom fields as columns in the member overview. For now by default with a flag set to true. ## What has been changed? - a flag show_in_overview has been added to custom fields via migration (default: true) - table component has been enhanced by a list of custom fields that is rendered as columns - The member live view passes custom fields to the table ## Definition of Done ### Code Quality - [x] No new technical depths - [x] Linting passed - [x] Documentation is added were needed ### Accessibility - [x] New elements are properly defined with html-tags - [ ] Colour contrast follows WCAG criteria - [x] Aria labels are added when needed - [x] Everything is accessible by keyboard - [x] Tab-Order is comprehensible - [x] All interactive elements have a visible focus ### Testing - [x] Tests for new code are written - [x] All tests pass - [x] axe-core dev tools show no critical or major issues ## Additional Notes <!--- Add any additional information for the reviewers here -->
carla added 1 commit 2025-11-20 09:03:24 +01:00
chore: add migration for show in overview flag
All checks were successful
continuous-integration/drone/push Build is passing
dec7550420
carla force-pushed feature/197_custom_fields_overview from dec7550420 to 6f6808d2ad 2025-11-26 14:43:31 +01:00 Compare
carla added 4 commits 2025-11-26 18:19:08 +01:00
carla added 1 commit 2025-11-27 14:10:37 +01:00
formatting
All checks were successful
continuous-integration/drone/push Build is passing
631cf23a0f
carla added 1 commit 2025-11-27 14:15:01 +01:00
translate: add translation
All checks were successful
continuous-integration/drone/push Build is passing
09c580e02d
carla changed title from WIP: Show custom fields per default in member overview closes #197 to Show custom fields per default in member overview closes #197 2025-11-27 14:15:25 +01:00
requested reviews from moritz, simon 2025-11-27 14:15:33 +01:00
carla changed title from Show custom fields per default in member overview closes #197 to Show custom fields per default in member overview closes #197 and #153 2025-11-27 14:17:07 +01:00
carla added this to the Sprint 9: 20.11 - 11.12 project 2025-11-27 14:17:29 +01:00
moritz approved these changes 2025-11-27 19:07:08 +01:00
moritz left a comment
Owner

Looks great. Maybe we could open a future issue for the in-memory sorting performance problem if the number of member is scaling.
Also some notes in the development-progress-log.md would be nice.

Looks great. Maybe we could open a future issue for the in-memory sorting performance problem if the number of member is scaling. Also some notes in the `development-progress-log.md` would be nice.
@ -165,0 +210,4 @@
cfv ->
formatted = Formatter.format_custom_field_value(cfv.value, custom_field)
if formatted == "", do: "", else: formatted
Owner

This line isn't doing anything?

This line isn't doing anything?
carla marked this conversation as resolved
@ -233,2 +329,4 @@
])
# Load custom field values for visible custom fields
custom_field_ids = Enum.map(socket.assigns.custom_fields_visible, & &1.id)
Owner

Maybe it would be less confusing if this overloaded variable would be called custom_field_ids_list and the other one custom_field_ids_set

Maybe it would be less confusing if this overloaded variable would be called `custom_field_ids_list` and the other one `custom_field_ids_set`
carla marked this conversation as resolved
@ -242,0 +353,4 @@
# Performance: This iterates through all members and their custom_field_values.
# For large datasets (>1000 members), this could be optimized by filtering
# at the database level, but requires more complex Ash queries.
custom_field_ids = MapSet.new(Enum.map(socket.assigns.custom_fields_visible, & &1.id))
Owner

custom_field_ids is already set. To reduce some code redundancy and computation overhead you could write:

custom_field_ids_set = MapSet.new(custom_field_ids_list)
`custom_field_ids` is already set. To reduce some code redundancy and computation overhead you could write: ``` custom_field_ids_set = MapSet.new(custom_field_ids_list) ```
carla marked this conversation as resolved
@ -245,0 +383,4 @@
# Note: We filter to visible custom fields after loading to reduce memory usage
# Ash loads relationships efficiently with JOINs, but we only keep visible ones
query
|> Ash.Query.load(custom_field_values: [custom_field: [:id, :name, :value_type]])
Owner

Is there a reason not to filter the custom_field_values directly in the DB? This would be much more efficient.

For example:

query
  |> Ash.Query.load(
    custom_field_values: fn custom_field_values_query ->
      custom_field_values_query
      |> Ash.Query.filter(expr(custom_field_id in ^custom_field_ids))
      |> Ash.Query.load(custom_field: [:id, :name, :value_type])
    end
  )
Is there a reason not to filter the custom_field_values directly in the DB? This would be much more efficient. For example: ``` query |> Ash.Query.load( custom_field_values: fn custom_field_values_query -> custom_field_values_query |> Ash.Query.filter(expr(custom_field_id in ^custom_field_ids)) |> Ash.Query.load(custom_field: [:id, :name, :value_type]) end ) ```
Author
Owner

No, good point!

No, good point!
carla marked this conversation as resolved
@ -0,0 +54,4 @@
defp format_value_by_type(value, :integer, _), do: to_string(value)
defp format_value_by_type(value, :email, _) when is_binary(value) do
Owner

:string and :email are formatted the same way, they could be merged:

defp format_value_by_type(value, type, _) when type in [:string, :email] and is_binary(value) do
`:string` and `:email` are formatted the same way, they could be merged: ``` defp format_value_by_type(value, type, _) when type in [:string, :email] and is_binary(value) do ```
carla marked this conversation as resolved
carla force-pushed feature/197_custom_fields_overview from 09c580e02d to 2284cd93c4 2025-12-01 08:57:27 +01:00 Compare
Author
Owner

Issue for in memory sorting: #222

Issue for in memory sorting: https://git.local-it.org/local-it/mitgliederverwaltung/issues/222
carla added 1 commit 2025-12-01 09:48:41 +01:00
performance: improvedd ash querying
All checks were successful
continuous-integration/drone/push Build is passing
b584581114
carla merged commit a132383d81 into main 2025-12-01 10:05:31 +01:00
carla deleted branch feature/197_custom_fields_overview 2025-12-01 10:05:32 +01:00
Sign in to join this conversation.
No description provided.