Membership Fee - Database Schema & Ash Domain Foundation closes #275 #283
No reviewers
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
2 participants
Notifications
Due date
No due date set.
Blocks
#284 Calendar Cycle Calculation Logic closes #276
local-it/mitgliederverwaltung
Reference: local-it/mitgliederverwaltung#283
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feature/275_member_fee_domain"
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?
Description of the implemented changes
The changes were:
Definition of Done
Code Quality
Accessibility
Testing
174b7696d3tocaebcefb8cWIP: Membership Fee - Database Schema & Ash Domain Foundation closes #275to Membership Fee - Database Schema & Ash Domain Foundation closes #275caebcefb8ctoa3aa61a89ea3aa61a89etoebbf347e42Good work. I just have the questions I mentioned, otherwise looks good to me :)
@ -0,0 +9,4 @@## Attributes- `name` - Unique name for the fee type (e.g., "Standard", "Reduced", "Family")- `amount` - The fee amount in the default currency (decimal)One member of the pilot clubs said they have the case that many members have individual fees. That would be possible that we define an amount on member level let's say?
In that case this club needs to define a member type for each member that has an individual fee. I think it's a quite special case, but it could be covered this way.
@ -17,2 +17,3 @@:house_number,:postal_code:postal_code,:membership_fee_start_dateI do not get why we need that as constant / member field? Isn't it always the join date + next cycle?
Sometimes the member should start to pay later or earlier then the joining date. This way the date when the cycles were generated can be modified.
@ -0,0 +50,4 @@),null: false# RESTRICT: Cannot delete fee type if cycles reference itWhat if members paid cycles in the past for a specific type and now this type changes?
As long as there are existing cycles paid in the past the referring type shouldn't be deleted, even if another type is now assigned to the member. Maybe we could implement in future a way to deactivate unused types. So they exist for the history but can not selected anymore.