Persistent Project + Date filtering with independent access and dynamic dependency

Ask for Help
1

Hello everyone,

I hope you’re doing well.

I’m reaching out to seek your help regarding an issue I’m facing in Grist, as part of a biannual project review in a PMO context.

:pushpin: Context

The application is built around three main tables:

  • PROJECT: Contains a list of 10 unique projects.
  • DATE: Contains a list of 20 unique dates.
  • DATA: Contains 200 columns (for simplicity, let’s focus on 14 key columns such as PROJECT, DATE, DESCRIPTION, RESPONSIBLE, RISKS, BUDGET, DURATION, etc.).

The data is displayed in different views (DESCRIPTION, CONTACTS, RISKS, BUDGET, DURATION), all filtered by two key criteria: PROJECT and DATE.

:dart: Objectives

  • Allow users to select a PROJECT and a DATE from any view.
  • Dynamically filter the displayed data based on the selected criteria.
  • Ensure that the filter is synchronized across all views of the application.

:gear: Constraints & Requirements

:white_check_mark: Independent filters for concurrent users

  • Each user should have their own independent filter.
  • One user’s filter selection should not affect other users.

:white_check_mark: Dependency between PROJECT and DATE filters

  • The DATE filter should dynamically adjust based on the selected PROJECT.
  • Only the dates associated with the selected project should be available in the list.

:x: Current issue: Persistent filtering across views

  • Problem: When a user applies a filter on PROJECT and DATE in one view, the filter does not persist when switching to another view.
  • Goal: Ensure that the selected filter remains active across all views until the user manually changes it.

If anyone has a solution or ideas on how to maintain filter persistence across pages, I would really appreciate your help.

Thanks in advance for your support! :blush:

2

I feel like you could potentially set up a user attribute table that would have reference columns to PROJECT and DATE. Then use row-level access controls that would “filter” the visible records in each view. You could probably expand that to where you apply row-level access to the user attribute table, so each user would only see their own row, and be able to select which project and date they want to “see” as they move through the various views.

Just brainstorming an idea for you, I don’t know if that would actually work in practice or not.

3

Hello,
I found it!!! :smiley:
Just need some time to implement the solution in a shareable environment, without sensitive data, and I’ll deliver everything to you…
The three constraints are met, notably through an ACL.
Stay tuned…
Thanks and have a great day!