Filters for Org model

[gabydisarli]

Issue description

We have a lot of filtering needs across the different tables in the Org model pages. We've designed some basic filtering so far, which is great for our non-org users. But we need to design a more robust filtering solution to meet this need. We're creating a ticket to design something that works for all the pages, instead of just the initial flows we've focuses on (domains, domain groups).

Considerations

In a recent demo, Cameron and some other folks mentioned they were concerned with showing statuses not available in the table. One example is Ineligible, which is a special status applied to someone in a unique circumstance (bad actor or not an government employee for example). We should consider the implications of showing unavailable statuses in this design. Are those statuses just hidden? Unselectable (disabled)? This should apply to all status filters.

Acceptance criteria

• [ ] Design a filter component that works across: Domains page, Domain request page, Archive requests page, and the Members page.
• [ ] Review initial designs with design team, product, and dev lead

Additional context

The steps below are a general checklist of the process to follow after designs have been created and are ready to share.

Phase 1: Team Review (#2455)

• Share with team for initial approval from PO/product approval
• Set up a Design/Dev review meeting with relevant devs to review designs and gather feedback
  • ❗ Smaller design updates will be made as part of this review period. Larger updates need to be a separate ticket. Avoid creating dev tickets before the design/dev review is complete unless it's determined that pieces of the work can be started before design has been finalized.
• Make any small updates needed as part of the team review period
• (optional) Reshare with PO/Product for final approval if needed

Phase 2: Feature Kickoff

• Meet with Dev, design, and product to demo approved feature, review any relevant artifacts, and discuss dev tickets

Links to other issues

🔄 Relates to: #2440

[PaulKuykendall]

Revisit the timing of this in Refinement, per New triage meeting.

[gabydisarli]

@PaulKuykendall I’ve removed the AC. “DEV tickets have been created and linked.” For these larger features, the development team will decide how they want to handle the tickets.

Historically, for smaller updates, the designer would create the dev ticket because it was a straightforward 1:1 arrangement. For these larger Org model features, the development team will likely break up the work into multiple tickets.

Therefore, it makes more sense for them to write their tickets. In the Feature Kickoff section, I’ve noted that we’ll discuss ticket creation with the dev team during that time. We’ll work closely with them to help create the tickets, but we won’t be creating the tickets ourselves.

[gabydisarli]

added new section to address feedback we had in demo on domain request status filters cc: @PaulKuykendall