WIP: feature/119_user_as_member #124
Labels
No labels
bug
duplicate
enhancement
help wanted
high priority
invalid
L
low priority
M
medium priority
needs refinement
question
S
UX research
wontfix
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: local-it/mitgliederverwaltung#124
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feature/119_user_as_member"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
It's still wip, but maybe someone can have a look. I have some trouble debugging the nested forms for editing existing users, that have related members.
@ -16,0 +82,4 @@<%= if @member_form do %><div class="ml-6 mt-4 p-4 bg-gray-50 rounded-lg"><.form for={@member_form} id="member-form" phx-change="validate_member" phx-submit="save_member"><.member_form form={@member_form} property_types={@property_types} />It only worked for me, if you use here
inputs_foras above. Only one submit button for the form is working. So save_member would never be triggered. You can remove the "Save member" button here and adjust the "Save" event to handle both - saving user and member. That worked for me.@ -136,0 +317,4 @@def handle_event("validate", %{"user" => user_params, "member" => member_params}, socket) domember_form = AshPhoenix.Form.validate(socket.assigns.member_form.source, member_params) |> to_form()user_form = AshPhoenix.Form.validate(socket.assigns.form.source, user_params)I had to change this to:
user_form = AshPhoenix.Form.validate(socket.assigns.form.source, user_params) |> to_form()to make it work
@ -22,0 +27,4 @@This creates a user and the notifier will automatically create a member."""def register_with_password(params) do# Use AshAuthentication's standard register_with_password actionWe defined this action ourselves, what does "standard action" mean in this context?
@ -67,1 +68,3 @@accept [:email]accept [:email, :member_id]argument :member, :mapchange manage_relationship(:member, type: :create)Does this mean that users will always have an associated member? I don't really remember what our plan was in this regard.
Also, I'm not sure how this interacts with the new
MemberCreationNotifierthat also creates members for users. Do we need both ways to create new members?@ -121,2 +139,3 @@validations do# Password strength policy: minimum 8 characters for all password-related actions# Password strength policy: minimum 8 characters# Note: register_with_password has built-in AshAuthentication validation, but admin_set_password doesn'tI don't see the validation in the action itself, is it defined in one of the two ash authentication changes?
@ -0,0 +1,50 @@defmodule MvWeb.MemberFormComponent doThis is pretty similar to the
MemberLive.Formliveview, can we extract some common code here?@ -112,0 +203,4 @@available_member_options =available_members_with_user|> Enum.filter(fn member -> is_nil(member.user) end)You can make this a bit faster by using something like this (relevant ash docs)
this way, the database will use the foreign key index to filter the members for you.
@ -112,0 +209,4 @@end)# Load PropertyTypes for MemberForm{:ok, property_types} = Mv.Membership.list_property_types()We could convert the
MemberForminto a LiveComponent. This way, it gets its ownmountfunction which we can move some of this logic into, making the user form page a bit smaller and easier to read.71e6308646toe74e7cbd31Pull request closed