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

Not showing multiple versions exist if the “versions” option is selected from the 3-dot menu #467

Closed
LisaMoore1 opened this issue Jan 15, 2020 · 5 comments

Comments

@LisaMoore1
Copy link
Collaborator

Ex. RAN099952 (TEST)

@calebissharp
Copy link
Contributor

@LisaMoore1 I would like some input on when you think it's most important to create new versions (or snapshots of the plan at certain points in time). Should it be every time it's saved? Every time the status changes, or maybe only for certain statuses? Or are we going to use it just for versions, and only create a new version/snapshot when an amendment is completed (either approved or rejected, and maybe discarded).

@LisaMoore1
Copy link
Collaborator Author

@calebissharp From the basic legal perspective we need a snapshot in time when something becomes the current legal version. That would mean:

  1. when a version (plan or mandatory amendment) is approved or
  2. a version started as a minor amendment is signed by all agreement holders (stands status).

Any other choices for snapshots in time would be for system functional purposes or some enhancement needs that I'm not currently aware of. I can ponder on this further but the two situations above are the only two that I can think of as must haves.

@calebissharp
Copy link
Contributor

@LisaMoore1 Is there no advantage legality wise to have more granular versioning? Even if it's just a nice-to-have feature? Because if that's the case, I think the versioning system we implemented was unnecessary, and we could have chosen a more maintainable and simpler solution. This pertains specifically to bcgov/range-api#120, where any new component of a plan that has to be versioned requires a significant amount of development time, and IMO adds more technical debt.

@micheal-w-wells
Copy link
Collaborator

Can we retroactively print a PDF of the plan and expect past data elements (AH, Staff, i.e. stuff on the PDF/RUP) to be there? If not, we missed the mark, and we’ll need to address the gap in a subsequent release to tomorrow’s. Whether or not we rewrite any of the versioning stuff is TBD based on what the PO says we have time for.

We talked, planned, and discussed a lot of potential solutions (my own included). Could write a novel but would rather not spend more time on it. As was discussed and planned previously, the needs still is:

To be able to see what any plan looked like at any approved/amended (legally standing) point in time.

I’ve said a number of times take the ‘greedy’ approach and version granularly, exposing what is needed to staff to avoid missing scenarios, help with troubleshooting issues with the site, and all around make reporting over time a robust capability.

@LisaMoore1
Copy link
Collaborator Author

Cleaning — and closing.

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

No branches or pull requests

3 participants