Verify Versions are getting created at the right time

[micheal-w-wells]

• [ ] when a plan is submitted to other party (so you can't see what they are working on)
• [ ] when it is approved, in any way.

The issue with the second one right now is it creates one on becoming approved and another identical one when the amendment process is started.

[micheal-w-wells]

716 should address this, the issue now is filtering on the front end for #700 , and in GET plan in the API (a work in progress). Leaving 'in progress' until all the PRs/UI etc are ready to mark this one for testing.

[micheal-w-wells]

marking as ready to test as it's done, just have to coordinate with UI merges then put in QA

[micheal-w-wells]

Caveat: does not create a new version when there is a change of AH. If this is what we need it needs to happen at FTA data import time.

[micheal-w-wells]

https://github.com/bcgov/range-api/pull/170 also addressed part of this

[micheal-w-wells]

I'm moving this to ready to test ahead of the web part being done as I can run a query for a given plan in test to verify that we have the right versions available for a given plan in Test. Ping me here with a RAN.

[LisaMoore1]

@micheal-w-wells I’m not sure how to test this one without being able to create amendments or see what is happening with all the “invisible” versions that are getting created.

[micheal-w-wells]

@LisaMoore1 if you can me a RAN (of a new rup you did since yesterday) and I'll give you a preview of what you would see if we had metabase in test (and what you will be able to see in production).

[LisaMoore1]

Micheal-w-wells RAN099916

[micheal-w-wells]

 id | plan_id |         created_at         | version | status_id | user_id | from_status_id | to_status_id | ef fective_legal_start | effective_legal_end | isprivacyversion 
----+---------+----------------------------+---------+-----------+---------+----------------+--------------+--- --------------------+---------------------+------------------
 84 |     194 | 2020-04-23 19:18:27.989+00 |       1 |         6 |      17 |                |            6 |                        |                     | t
 85 |     194 | 2020-04-23 19:19:32.837+00 |       2 |         1 |       8 |              6 |            1 |                        |                     | f
 86 |     194 | 2020-04-23 19:20:24.301+00 |       3 |        13 |      17 |              1 |           13 |                        |                     | t
 87 |     194 | 2020-04-23 19:25:52.154+00 |       4 |        19 |       8 |             13 |           19 |                        |                     | t
 88 |     194 | 2020-04-23 19:28:02.54+00  |       5 |        18 |      14 |             19 |           18 |                        |                     | t
 89 |     194 | 2020-04-23 19:28:58.685+00 |       6 |        14 |      17 |             18 |           14 |                        |                     | t
 90 |     194 | 2020-04-23 19:30:14.632+00 |       7 |         5 |      14 |             14 |            5 |                        |                     | t
(7 rows)  

[micheal-w-wells]

@LisaMoore1 can just ignore the privacy column as it's still WIP. I should clarify though that it is a 'calculated on the fly' column vs one stored in a table, meaning we won't have to update/muck with data once I get it working.

[LisaMoore1]

@micheal-w-wells That’s really helpful. Thank you. Why does version 2 (1-C) have “effective _legal_end” as “f” but all the rest are “t”?

[micheal-w-wells]

@LisaMoore1 there was a whitespace issue and you weren't seeing those last few columns show up. effective start and end dates are only populated (with dates) for legal status versions. The 't' and 'f's are part of the WIP privacy stuff.

[micheal-w-wells]

If you look at the table i fixed it so it will read correctly

[LisaMoore1]

Alrighty. If you don’t see any reason why not to I’m closing this one now.