Entity UI - Display entity as historical

[lmcclung]

Background

We currently file dissolutions using a jupyter notebook. The filing is ledgered as a voluntary dissolution and the details within state the dissolution date. However it would be nice to make it clear when an entity is no longer active and prevent users from starting a change of address, change of directors or alteration.

Once we set the dissolution date in the backend, and set it in the current state table, we know the entity is historical and can display it.

Description

Display that entity is historical. Include:

• [x] State (Historical)
• [x] What caused change of state (Administrative Dissolution, Voluntary Dissolution, etc.)
• [x] Effective date of when state changed

Design Ticket: https://app.zenhub.com/workspaces/entity-5bf2f2164b5806bc2bf60531/issues/bcgov/entity/9155

Requirements document on states: https://docs.google.com/document/d/1dPQmA-fKMwGXG1uHAcN3-hDZCOAqmvTkiO7BHARi8no/edit?usp=sharing

Possible dissolution types

From use case docs (Do not need to display abbreviations in UI): Historical – Amalgamated (HAM) Historical – Amalgamated with a Foreign Corporation (HAO) Historical – Amalgamated into a Foreign Jurisdiction (HAO) Historical – Withdrawn (HWT) Historical – Continuation Out (HCO) Historical – Liquidation (HLD) Historical – Dissolved for Other Reason (HDO) Historical – Voluntary Dissolution (HDV) Historical – Dissolved for Failure to File (HDF) Historical – Administrative Dissolution (HAD) Historical – Expired Limited Restoration (EXR)

From Linda looking in Oracle (I would trust this one)

[sienna-oldaccountdontuse]

See section "Filings that can be filed post-dissolution" https://docs.google.com/document/d/1pJM2mUoG5ln6eiopole3BY5PBAExESBGz4cRYdnDG58/edit?usp=sharing @lmcclung am i correct that only staff can file those filings?

[sienna-oldaccountdontuse]

@Sienna-Blumstengel attach list of possible dissolution types

[sienna-oldaccountdontuse]

2 fib

[severinbeauvais]

I've provisionally assigned this to myself so that I can manage this code change along with the code change in 8822.

[severinbeauvais]

deleted obsolete comment

[severinbeauvais]

@sienna-blumstengel @lmcclung @thorwolpert Can one of you make sense of this for me...?

At one time it appeared that we had 5 types of dissolutions:

1. administrative
2. court ordered liquidation
3. involuntary
4. voluntary
5. voluntary liquidation

But now, looking at the list and table in this ticket's description, we have separate lists with some common and some non-overlapping types. Eg,

  DISS_1_FILE = 'Dissolution 1 - Fail to file',
  DISS_1_ADMIN = 'Dissolution 1 - Admin',
  DISS_2_FILE = 'Dissolution 2 - Fail to file',
  DISS_2_ADMIN = 'Dissolution 2 - Admin',
  DISS_OTHER = 'Dissolved for Other Reason',
  DISS_VOLUNTARY = 'Voluntary Dissolution',
  DISS_FAIL_FILE = 'Dissolved for Failure to File',
  DISS_ADMIN = 'Administrative Dissolution',
  DISS_1_TRANS = 'Dissolution 1 - Fail to Transition',
  DISS_2_TRANS = 'Dissolution 2 - Fail to Transition',
  DISS_FAIL_TRANS = 'Dissolved for Failure to Transition',
  DISS_LLP_REG = 'Dissolved from LL Partnership Reg',
  DISS_CONVERTED = 'Converted to BC Company',

Can you provide me with an (initial) list of dissolution types that we will be reporting via LEAR? Thanks!

[severinbeauvais]

Most code changes have been made. The only thing missing is getting the entity's dissolution info from the API and determining what the dissolution types are (ticket 9348). To prevent the UI changes from going stale, they will be merged ASAP; this feature is blocked by a hard-coded getter value so, other than the collateral UI cleanup, this code change should not affect anything.

Sample historical state (staff view):

Sample completed dissolution (staff view):

The draft dissolutions should look like the existing draft tasks (common code).

The future effective, and future effective pending dissolutions should look like IAs and alterations (common code).

[severinbeauvais]

Since I followed the UI designs, I did some of the work for 8822 in THIS ticket. Therefore, I am changing this ticket's estimate to 3, and that ticket's estimate to 2.

[severinbeauvais]

Test Notes (Part 1)

The main "historical" functionality is current disabled (with a hard-coded getter value), so the functionality changes so far are not testable... but the UI tweaks can be verified:

• fonts are consistent throughout the app
• filing history list detail panels are consistent (for all types of filings/states)
• todo list detail panels are consistent (for all types of tasks/states)
• font size and contact info is consistent across all dialogs
• long dates now display full month (eg, November instead of Nov)
• generally, colours are consistent and and elements line up

[severinbeauvais]

Part 1 is now merged and deployed to Dev.

I'm moving this ticket back to In Progress until the dependencies are resolved, and then I can work on Part 2.

[severinbeauvais]

As per the RFC, the API will provide several new variables to describe the business' current state/compliance/standing/etc. Handling this change in the UI (in THIS ticket) probably fits within the current estimate.

However, the RFC also mentions the management of "allowable actions" depending on the business' states, which the UI should query and act upon. This would require some refactoring of the UI code (possible new API call, new data structure for actions, and replacement of existing business logic). This is a small to medium change, which should be its own ticket. See new ticket 10369.

[severinbeauvais]

Although blocked by the finer details, I have resumed work on this ticket in order to flesh out the known/planned "allowable actions" architecture. I will make this change compatible with the existing functionality and easy to switch to when this info comes from the API. This is a precursor to #10369.

[severinbeauvais]

~I am still blocked by some final design decisions on entity state, including whatever we do with Pending Dissolution and Not In Good Standing info (state?).~ we are not handling Pending Dissolution atm

[severinbeauvais]

As discussed in standup today, we are adding "Not In Good Standing" work to this ticket (vice creating a new ticket, since it's in the same area I'm already working in).

From @tlebedovich :

Yes there are differences in the UI; For Not in Good Standing - we allow the user to click the Change Company Information and Dissolve this Company buttons in the tombstones, but each would open the “Not in Good Standing” modal. (we still have to build the modal for Change Company info and update that function). Also in the future, we will show some kind of visual tag/badge, similar to the historical tag, that will say “Not in Good Standing”. There will also be similar tags in the future for other statuses.

[severinbeauvais]

The scope (and therefore effort) of this ticket has grown due to:

• refactoring state as per schema/API changes
• centralizing "allowable actions" to make current and future work easier
• updating code due to new NIGS requirements
• fixing a few small bugs (minor effort)
• a bunch of extra unit tests

This is now a "5". We could have created separate tickets for some of the above but we didn't because it's all in the same area of code so needs to be worked on serially, or by just one person (me).

[severinbeauvais]

Test Notes (Part 2)

• Verify BC Business Registry has been replaced with BC Registries everywhere (except ledger item "filed by").
• Verify that changing email and phone number is always enabled.
• Verify that staff comments are always enabled.
• Verify that staff detail comments are always enabled.
• Verify that staff filings are disabled when the business is historical.
• Verify that filing a correction is disabled when the business is historical.
• Verify that no other company changes/filings can be made when the business is historical.
• Verify that clicking Change Company button displays a dialog when the business is NIGS.
• Verify that clicking Dissolve button displays a dialog when the business is NIGS.
• Verify that all other filing can be made (per previous rules) (regression testing).
• Verify info header badge and reason when the business is historical.
• Verify that Business Identifier (eg, BC1234567) is displayed everywhere it should be (regression testing).
• Verify save/resume/file of AR/COD/COA (regression testing).
• Verify that info header displays either entity subtitle or IA subtitle (not both).

[severinbeauvais]

This is now deployed to Dev, and I have tested some of the items above. I need the latest API code to test actual historical filings.

[severinbeauvais]

@tlebedovich @yuisotozaki

In the meantime, some UX Assurance can be performed, both to validate the test items above and to look at the changes in Dev.

[severinbeauvais]

^^ This is now testable, but it only works on new dissolutions.

[tlebedovich]

@severinbeauvais PayBC is down at the moment in DEV so I can't complete a dissolution to see historical - do you have any historicals I could see somewhere in DEV?

two questions based on your testing notes above; 1) I missed the decision where we are changing all instances of Business Registry to BC Registries - does Scott/Linda know this? 2) Linda had previously ok'd my design comps that deactivated/turned off the ability to edit the email/phone in the header bar once the company filed a dissolution - just wanted to see if the decision was changed to now allow users to continue to update this information even when there is a dissolution pending/filed? Again, I may have missed an updated decision, I just wanted to double check - https://projects.invisionapp.com/share/XY11SF2SDP27#/screens/458578893

c/c @forgeuxGH5 @sienna-blumstengel

[severinbeauvais]

Here is a historical BC Benefit Company: https://dev.bcregistry.ca/business/BC0870824 (BCREG0020)

1. I remember discussing a change to BC Registries, and since I had to update one instance, I did the rest (to be consistent with header, etc). Do I need to revert this?

2. I asked Linda specifically if email/phone should stay editable even after dissolution and she said yes.

[tlebedovich]

1. just wondering if I should take a look to see what instances were changed to make sure it makes sense still - any way for me to see where the naming updates that were made?
2. Haha, ok, fine by me.

[severinbeauvais]

You can go here and search (CTRL+F) for "BC Registries". Left side is old code. Right side is new code. There are 24 instances. https://github.com/bcgov/business-filings-ui/pull/268/files

[tlebedovich]

@severinbeauvais - not including wording edits (to come), here was the UXA from me:

• [ ] bold "Historical" text in badge
• [ ] remove the hover effect on the badge (it highlights a bit which makes it seem clickable)
• [ ] fix wrapping of historical text so it aligns with the email/phone/number text in mobile
• [ ] not part of this ticket, but noticed the subhead "BC Benefit Company" should be the same 495057 colour as the Vol Diss text (it was at some point)

[severinbeauvais]

This is the badge bolded. Look OK?

I also disabled the pointer events on it (which removes the hover styling).

[severinbeauvais]

I can't fix the wrapping easily. That is one long line, not separate blocks. I see you're using a narrow window, and supporting responsive layout should be another ticket.

[severinbeauvais]

I changed the colour on the subtext. It was explicitly set to #212529 so that must have been taken from some design page at some point. Anyway, it's #495057 now.

[tlebedovich]

Its ok it is wrapping, just wanted it to wrap in alignment with the other text. I can make a separate ticket.

[severinbeauvais]

Its ok it is wrapping, just wanted it to wrap in alignment with the other text. I can make a separate ticket.

OK. It will require refactoring the layout of the elements in that entity info component. Isn't there already a ticket for that?

[tlebedovich]

@severinbeauvais Copy UXA is complete with notes for you. Anything without comments is good to proceed with the updates you made.

[severinbeauvais]

The changes requested in this ticket's PR (and above) have been copied to 10464.

THIS ticket can now go to RFQA. (The new ticket will go through UXA for one last look.)