Create UI: add rule to block TING if it has a pending filing (was: pending dissolution / draft filing)

[severinbeauvais]

Block a TING with a PAID or PENDING dissolution filing in its Filing History List. (SB verified the other statuses with Argus and these 2 are the only ones to block.) (Actually, the better way to do this is check whether the filing is not completed and not corrected.)

There is no need to block a TING with a New/Draft/Pending/Error/Paid filing in its Todo List, as per requirements:

[severinbeauvais]

deleted obsolete comment

[severinbeauvais]

What was decided:

• if TING has a pending filing in the Todo List, the Filer should ignore it
• if TING has a dissolution filing pending then TING cannot be part of amalgamation; any other pending filing (that doesn't make the TING historical) should be ignored by the Filer

[severinbeauvais]

@Mihai-QuickSilverDev We do not have a UI design for displaying a message that a TING has outstanding filings (drafts or pending) in its Todo List. Please create a new ticket (not MVP?) if required.

[severinbeauvais]

Test Notes

In this ticket...

1. the check for a future effective filing was fixed - PR 620
2. the race condition that sometimes showed businesses that are not in LEAR as Foreign was fixed see comments below - no PR
3. a TING validation rule was added to block the business if it has any pending filings - PR 621 and PR 622

[severinbeauvais]

Re:

2. the race condition that sometimes showed businesses that are not in LEAR as Foreign was fixed (PR TBD) (try it by adding BC0730025)

@yuisotozaki This is about the difference you see when trying to add a CCC as staff vs reg user (though it's not specific to CCC).

As staff, if the business cannot be looked up in Auth/LEAR, we display that it doesn't exist in LEAR.

As a reg user, if the business cannot be looked in Auth/LEAR, we assume it's simply not affiliated to the current account.

Should we just leave it like this? Any ideas how this would work ideally?

[yuisotozaki]

I think the subtle differences in the messaging to non-staff and staff is meaningful here.
Staff understands LEAR and how the entities are stored in different systems; giving them a heads up helps them with troubleshooting.
Non-staff just needs to know that they don't have access to such entity.

[severinbeauvais]

Thanks, Yui.

In fact, it wasn't a race condition at all: the code makes calls to auth and legal APIs concurrently but already checks the results in the correct order (ie, auth response first).

So, I'm not doing anything about "issue 2".

[yuisotozaki]

Ready for QA!