-
Notifications
You must be signed in to change notification settings - Fork 59
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
Auth Web staff dashboard: submitter should not be "undefined" #24080
Comments
Duplicate ticket: #24078 |
Also, the line should say "Authorization Submitted" (not Application). |
@jacqueline-williams-549 @janisrogers Please see the description for possible options. Do you have a preference? Thanks! |
My preference would be option 1, but I am okay with option 2. |
@OlgaPotiagalova Could you please decide whether we should implement option 1 or option 2? Option 1 is more work (est: 1 for UI, 2 for API) but provides a better experience because it should the submitter name. Option 2 is almost no work (est: 1 for UI). |
Blocked while awaiting PO decision. |
Considering the release timeline and the effort, please implement solution 2 for now. Create a separate ticket(s) to capture the submitter information (from login account), model it in the db, and display it in the staff dashboard, for future implementation. |
@ArwenQin Please work on this ticket. See comments above for the decisions we made. |
Created #25230 for future implementation. |
Deployed to PROD, this is low risk (small wording change see PR bcgov/sbc-auth#3202 also I don't think continuation IN is active on PROD). |
The original submitter name shows as "undefined".
The re-submitter name is not even shown.
The root cause is that we no longer capture the Completing Party as this is an authorization only -- but we do have the submitter's login. (Note that we also don't support multiple submitters.)
Option 1: Show the authorization submitter from the filing's
header.submitter
property. (Right now this is the encoded login but we could update the review endpoint to provide the decoded name.) We would only be able to display one submitter -- the original one or the latest one. I suggest the latest one as being most useful.Option 2: Don't show the authorization submitter, since we already don't show it for a resubmission.
The text was updated successfully, but these errors were encountered: