You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're transitioning to a world where memberships end on the day and month they were activated, at the end of however many years were paid for. Until all of the active memberships have expired, the calculated end date will differ from the actual end date. The actual end date should win.
As an admin...
...when I add a new member (new address, or splitting an address up) the end date should be pre-filled with the new rules for an end date (start date + n years)
...when I edit an existing address's membership, and I change the start date, the end date should be pre-populated using the new rules. If I edit name, etc. (something other than the membership start date) the end date should be left alone.
...when I import the spreadsheet of members, the end date in the spreadsheet should serve as the "real" end date in the system. The spreadsheet's end date should win, if there is a discrepancy.
TODO: Is this correct?
...when I export the spreadsheet, the end date should use the saved override values but not populate with a calculated value on the fly.
...when I view a member, I should see the expected/calculated end date in a minimal way for visual comparison with the actual end date.
As a developer...
I should be able to easily access both the real and calculated end dates for a member in the console.
The text was updated successfully, but these errors were encountered:
We're transitioning to a world where memberships end on the day and month they were activated, at the end of however many years were paid for. Until all of the active memberships have expired, the calculated end date will differ from the actual end date. The actual end date should win.
As an admin...
n
years)As a developer...
The text was updated successfully, but these errors were encountered: