-
Notifications
You must be signed in to change notification settings - Fork 19
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
Allow election directories to be moved #38
Comments
There historical data changes means only the URL changes right?? Or does reorganizing changes other things as well? If yes what data are we losing?? Also, in the new approach. How will we manage the elections keys(electionID)?? We need them to be unique and consistent. How we are ensuring keys are unique? |
@kalkayan well, if we offer alphanumeric keys, then it's up to the user, and also reasonably easy -- just suggest that the date be part of the key (e.g. "2021-steering"). This also would let us have cleaner code for the URLs; we could use the key instead of the directory structure. This would limit keys to characters that can be used in a URL, but again not hard. |
Ya, 2021-steering sounds much better and even if they collide we can print a small warning message for admins to fix electionID. |
OK, lemme look at doing this. I'll require us to have an ID/dir map instead of just a "key" as a class attribute, so I'll need to tinker around a bit. |
The way it is now:
Elections are identified by their directory location. This is very easy for setup. However, it also means that if a user reorganizes their repository and moves the election directories around, they lose all historical election data.
Proposed solution:
election.yaml
should contain a user-selected "ElectionID" (alphanumeric) that does not change. This could then be used as the key for election continuity rather than the directory location.@kalkayan thoughts?
The text was updated successfully, but these errors were encountered: