[BUG]: membership application cannot be accepted

carla commented

2026-04-27 08:15:05 +02:00

Owner

Expected Behavior

A membership application is accepted when I approve it and the member is added.

Current Behavior

I get an error clicking on approve

Possible Solution

Maybe it is connected to a required datafield (Mitgliedsnummer) that I do not have as field in my form? But even if I mark the datafield as not required I get the same behaviour for the existing application.

Steps to Reproduce

Fill out a membership application
2.As admin click on approve
You get an error message: Mitgliedsantrag konnte nicht angenommen werden

## Expected Behavior A membership application is accepted when I approve it and the member is added. ## Current Behavior I get an error clicking on approve ## Possible Solution Maybe it is connected to a required datafield (Mitgliedsnummer) that I do not have as field in my form? But even if I mark the datafield as not required I get the same behaviour for the existing application. ## Steps to Reproduce 1. Fill out a membership application 2.As admin click on approve 3. You get an error message: Mitgliedsantrag konnte nicht angenommen werden

carla added the

bug

label 2026-04-27 08:15:05 +02:00

simon added this to the Sprint 16: 04.05.-22.05. project 2026-05-05 16:29:33 +02:00

simon commented

2026-05-05 16:50:22 +02:00

Owner

Can't reproduce the issue on members.test.kollicloud.de

Can you provide more details on the setup (e.g. instance, selected fields, maybe error message from browser console or even server logs?)

Can't reproduce the issue on members.test.kollicloud.de Can you provide more details on the setup (e.g. instance, selected fields, maybe error message from browser console or even server logs?)

carla commented

2026-05-05 19:38:36 +02:00

Author

Owner

It is the local-it.org instance, so easiest for you would be trying to accept the open application there

👍 1

simon commented

2026-05-05 21:39:09 +02:00

Owner

Ah! We have some logs to investigate then:

V2026-04-23T12:42:31.098128546Z 12:42:31.079 [notice] SIGTERM received - shutting down
 2026-04-23T12:42:31.110915982Z
�2026-05-05T19:37:17.722928791Z 19:37:17.721 [warning] One or more `after_transaction` hooks on `Mv.Membership.Member.create_member` are being executed,
T2026-05-05T19:37:17.723191395Z but there is an ongoing transaction still happening.
 2026-05-05T19:37:17.723261183Z
�2026-05-05T19:37:17.723307583Z This means that you may be running an action in a transaction that you did not design with the intent of running in a surrounding transaction.
12026-05-05T19:37:17.723354795Z You should either
 2026-05-05T19:37:17.723408878Z
�2026-05-05T19:37:17.723453087Z 1. If you are testing, and your data layer runs in a transaction/sandbox mode, set `config :ash, warn_on_transaction_hooks?: false` in `config/test.exs`
�2026-05-05T19:37:17.723548222Z 2. Create another action that is safe to use in a surrounding transaction, and use that instead of this one
�2026-05-05T19:37:17.723600695Z 3. Silence this warning using `set_context(%{warn_on_transaction_hooks?: false})` in the action definition
�2026-05-05T19:37:17.723643026Z 4. If building a changeset manually, do #2 except programmatically, `Ash.Changeset.set_context(changeset, %{warn_on_transaction_hooks?: false})`
 2026-05-05T19:37:17.723691284Z
-2026-05-05T19:37:17.724829033Z 19:37:17.723 [warning] Failed to approve join request abff7c2f-2cf7-46e9-8361-95449c853761: %Ash.Error.Invalid{bread_crumbs: ["Error returned from: Mv.Membership.Member.create_member"],  changeset: "#Changeset<>",  errors: [%Ash.Error.Changes.InvalidAttribute{field: :join_date, message: "is invalid", private_vars: nil, value: "24.4.2026", has_value?: true, splode: Ash.Error, bread_crumbs: ["Error returned from: Mv.Membership.Member.create_member"], vars: [], path: [], stacktrace: #Splode.Stacktrace<>, class: :invalid}]}

Ah! We have some logs to investigate then: ``` V2026-04-23T12:42:31.098128546Z 12:42:31.079 [notice] SIGTERM received - shutting down 2026-04-23T12:42:31.110915982Z �2026-05-05T19:37:17.722928791Z 19:37:17.721 [warning] One or more `after_transaction` hooks on `Mv.Membership.Member.create_member` are being executed, T2026-05-05T19:37:17.723191395Z but there is an ongoing transaction still happening. 2026-05-05T19:37:17.723261183Z �2026-05-05T19:37:17.723307583Z This means that you may be running an action in a transaction that you did not design with the intent of running in a surrounding transaction. 12026-05-05T19:37:17.723354795Z You should either 2026-05-05T19:37:17.723408878Z �2026-05-05T19:37:17.723453087Z 1. If you are testing, and your data layer runs in a transaction/sandbox mode, set `config :ash, warn_on_transaction_hooks?: false` in `config/test.exs` �2026-05-05T19:37:17.723548222Z 2. Create another action that is safe to use in a surrounding transaction, and use that instead of this one �2026-05-05T19:37:17.723600695Z 3. Silence this warning using `set_context(%{warn_on_transaction_hooks?: false})` in the action definition �2026-05-05T19:37:17.723643026Z 4. If building a changeset manually, do #2 except programmatically, `Ash.Changeset.set_context(changeset, %{warn_on_transaction_hooks?: false})` 2026-05-05T19:37:17.723691284Z -2026-05-05T19:37:17.724829033Z 19:37:17.723 [warning] Failed to approve join request abff7c2f-2cf7-46e9-8361-95449c853761: %Ash.Error.Invalid{bread_crumbs: ["Error returned from: Mv.Membership.Member.create_member"], changeset: "#Changeset<>", errors: [%Ash.Error.Changes.InvalidAttribute{field: :join_date, message: "is invalid", private_vars: nil, value: "24.4.2026", has_value?: true, splode: Ash.Error, bread_crumbs: ["Error returned from: Mv.Membership.Member.create_member"], vars: [], path: [], stacktrace: #Splode.Stacktrace<>, class: :invalid}]} ```

simon commented

2026-05-06 14:30:31 +02:00

Owner

Fixed via the recent join form date-field update in #492: join_date is now handled as a proper HTML date input, so new join requests store a valid ISO date instead of localized free-text values like 24.4.2026. That invalid date format was the root cause of the approval failure (create_member → join_date is invalid) seen in this issue. With this change, the reported failure no longer occurs for newly submitted requests.

simon closed this issue

2026-05-06 14:30:34 +02:00

Rows
Columns

[BUG]: membership application cannot be accepted #483

Expected Behavior

Current Behavior

Possible Solution

Steps to Reproduce