Closed mstanton1 closed 1 year ago
Hey team! Please add your planning poker estimate with Zenhub @cameron-eyds @chdivyareddy @dimak1 @doug-lovett @owillborn
@cameron-eyds found one little thing to fix. I don't think I can submit payments to check folio number..right? 🤔
Max. characters should be 30 (for both registrations and transfers)
Ah yes, i didn't update the existing Staff Payment, will do so! 👍
I'm not sure, you should be able but will need a valid BC ONLINE account number for Dev, i don't have one actually. Divya might?
@saragunnarsson Ah, to follow up here. The StaffPayment component is a Shared Component. Meaning this used by many of the projects. This input field was set to 50 chars for all projects, did something change on the back end to reduce the char count to 30 or is 50 still ok?
Only reason i ask is because this is what several of the projects use and if we change the char count, it will change for all instances of this in other projects, when they update the version.
oh good question. I'm not sure... @tlebedovich do you know the answer to @cameron-eyds question?
@cameron-eyds The Folio max character for MHR (Staff and Qualified Supplier fields that show in all MHR transactions) needs to be able to fit into the legacy MHR database for now, which I believe is only 30 characters. Is this correct @doug-lovett ?
But I would think that we shouldn't mess with the max Folio character count for the other applications that use this component.
@mstanton1 - please see above
Fair enough! We could localize the 'Shared Component' and overwrite this though as an option? It would disconnect it from the shared version but this is also something we might have to do with upcoming Vuetify Changes anywho.
So there is options for sure!
ok great - let's wait for Doug to confirm the 30 max for MHR folio before deciding. once we move to new DB, we can up it to 50 like all the others I would assume.
Since we move off DB2 soon enough and historically speaking it's rare to have a folio beyond 30 characters I'm almost inclined to just leave it as 50. Worst case scenario we generate an ops ticket or two in the time between moving to Postgres. @doug-lovett do you have access to look up the folio field in Postgres to see if in the other apps there's very many cases where it goes beyond 30, just to confirm my understanding that long folio is rare?
Hey @doug-lovett Just wanted to see if you had a chance to look at the above?
@mstanton1 @saragunnarsson for PPR here are the counts where the length > 30: Search: 216 out of 1,218,758 Registrations: 602 out of 912,614
Awesome. With the low number of folios over 30 characters I don't think we need to bother updating the UI to 30 while on DB2 and then switching back to 50. If the work hasn't already been done we can just leave this at 50 characters now.
Ok perfect, then I'll move this along. Thanks! @doug-lovett @mstanton1
@cameron-eyds , For the MH Registration, when the Folio is entered in the staff payment (BC Online), it is not displayed in the registration table, transactions history and in the output tombstone. Please take a look, thanks!
MHR Number: 150589 in DEV.
Submitting party:
Staff Payment:
Registration table:
Transactions History:
Registration output:
https://app.zenhub.com/files/157936592/7e337965-c3a8-43b3-a021-b2549063fc64/download
@divyav-aot Interesting, i didn't modify the Staff Payment Component. Perhaps has this never carried through? Can look on Monday though!
I verified the 2nd bullet, so most likely another issue.
@cameron-eyds oh okay, got it...So, for the PPR there was a separate field in the registration process to enter the Folio number, but I believe in the MHR for the staff account, only way to enter the folio is through the staff payment component.
Updated for Transfers!
@cameron-eyds , For the folio number I noted that in the MHR table and in the outputs, only 30 characters are displayed when 50 characters are entered which is maximum, in the transaction history it is displayed as expected which is 50. Please take a look at it, thanks!!
Expected Folio number: F8478326-S726349/82347283478S723487234882734887822
Current Behavior: Staff payment before submission:
MHR Table:
Transfer output: https://app.zenhub.com/files/157936592/17cf4bb9-9698-4123-a5f1-cdba012775f3/download
Transaction History:
There was discussion around this above. The shared components validation is for 50, as that is consistent throughout the applications, it may be that DB2 is the exception. Either way, i believe this falls outside the scope of the UI now at this point. There was some discussion to adjust the limit down to 30 but since this is shared, they opted to leave at 50, since i believe it won't be an issue when we move off DB2. But yes, i'm no sure there is any further work in this UI ticket.
Ah..okay, I will move this ticket along for now and can discuss with @mstanton1 later on the consistency on the UI, thank you!!
@cameron-eyds , Sorry I missed the Folio for the Registration flow, was this only updated to Transfers? I just tried in the Registration flow and it is not displayed on the UI (MHR table, Transactions and outputs). Can you please take a look, thanks!!
Eg: MH Registration 150590 in DEV.
@chdivyareddy ~Sorry Divya, once again i think we need to create a new ticket for this. This task was called out explicitly for Transfers.~ ~It is a super quick task for sure but for visibility and keeping consistent with the scope of our tickets, i think it would be good to have a small task to make this change.~ ~Apologies!~
Sorry, apologies from my end, forget what i mentioned there. It does call out registrations in the Title of the ticket, can have a look. I think the missed scope of this ticket was the Staff Payment was assumed to have been working.
@cameron-eyds Sure, will create a new one, thank you:)
hahah...no worries, all good!
@chdivyareddy please tag @mstanton1 and myself with your new ticket so we can maybe pre-groom anything remaining tomorrow.
No new ticket required, my blunder here! I misread the title, will have a look at Registrations instance of StaffPayment as well 👍
Divya, update is now in Dev! Sorry for the hassle here, 11 commits later (although i could be getting my tickets mixed up haha)
No worries, thanks for the quick fix Cameron:)
Verified in DEV with MHR Number 150594.
Staff payment:
MHR Table:
Transactions History:
Registration output: