Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure rollover memberships reference the most recent membership #2102

Open
maneesha opened this issue Nov 19, 2021 · 4 comments
Open

Ensure rollover memberships reference the most recent membership #2102

maneesha opened this issue Nov 19, 2021 · 4 comments

Comments

@maneesha
Copy link
Contributor

If we roll over a membership, we should have some verification that it is rolling over from the most recent membership.
For example, suppose membership ABC had one term that went 2019-06-01 to 2020-06-01 and an other that goes from 2020-06-01 to 2021-06-01. If we try to do a roll over from the 2019-2020 membership to create a 2021-2022 membership, then we should get a warning that an intermediate membership exists. The membership should be compared by both the name and the main organization.

I'm not sure what the best logic would be to apply this warning, so putting this out here for consideration.

@pbanaszkiewicz
Copy link
Contributor

Is it currently possible to again roll over an already rolled over membership?
If yes, then this is an issue because it's not supported by the database design. We only keep track of the single "rolled-over-to" membership.

In case of the warning, we could generate a warning box on top of the "roll over" form.

@maneesha
Copy link
Contributor Author

A membership should be rolled over only once.

The example I refer to above is when we have a 2019-2020 membership and a 2020-2021 membership, but the second one wasn't created as a rollover since we didn't have the feature then.

A warning box at the top of the form would work.

@pbanaszkiewicz
Copy link
Contributor

Wouldn't it be simpler to produce an administrative job (script) to find all unconnected memberships from consecutive years and then connect them? And then leverage mechanisms preventing multiple roll overs?

I guess it wouldn't prevent users from entering new (disconnected) memberships for organisation X...

Well, my final thought is that it's tricky to accurately tell that user is entering data for membership that may already exist in the system. What if it's a consortium which changed by only one member organisation? What if there's a slip between memberships and there are a few days "in books" without membership coverage?

We may want to discuss this on Friday's call.

@maneesha
Copy link
Contributor Author

maneesha commented Dec 3, 2021

If we complete #2101 then this is low/non-prioirty.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants