Dataview Grid table

[uzairali19]

This pull request introduces a new "Audit Trail" page featuring a filterable, sortable, and paginated table for inspection traceability and accountability. It adds a reusable generic table state, integrates the new page into the sidebar and routing, and includes supporting style and dependency updates. Additionally, there is a temporary change to the authentication service that disables password verification.

Audit Trail Table Feature:

• Added a new filter_table_demo.py page that displays an "Audit Trail" using the FilterTable component and the new GridState for managing table data, filters, sorting, and modal state. (mindtrace/apps/mindtrace/apps/poseidon/poseidon/pages/filter_table_demo.py, mindtrace/apps/mindtrace/apps/poseidon/poseidon/pages/filter_table_demo.pyR1-R15)
• Implemented GridState, a reusable state class providing static table data, filter configuration, sorting, pagination, and modal logic for the audit trail table. (mindtrace/apps/mindtrace/apps/poseidon/poseidon/state/grid_state.py, mindtrace/apps/mindtrace/apps/poseidon/poseidon/state/grid_state.pyR1-R252)
• Registered the new page in the app's routing and sidebar navigation, making it accessible via /filter-table-demo and adding an entry labeled "Audit Trail with Modal". (mindtrace/apps/mindtrace/apps/poseidon/poseidon/poseidon.py, [1] [2]; mindtrace/apps/mindtrace/apps/poseidon/poseidon/pages/__init__.py, [3] [4]; mindtrace/apps/mindtrace/apps/poseidon/poseidon/components_v2/layout/sidebar/sidebar.py, [5]

Supporting Updates:

• Added a new table style variant table_accordian for future table UI improvements. (mindtrace/apps/mindtrace/apps/poseidon/poseidon/styles/variants.py, mindtrace/apps/mindtrace/apps/poseidon/poseidon/styles/variants.pyR280-R284)
• Added reflex==0.7.6.post1 to requirements.txt to ensure the required UI library is available. (mindtrace/apps/mindtrace/apps/poseidon/requirements.txt, mindtrace/apps/mindtrace/apps/poseidon/requirements.txtR1-R2)
• Updated .gitignore to exclude .env.dev files. (mindtrace/apps/mindtrace/apps/poseidon/.gitignore, mindtrace/apps/mindtrace/apps/poseidon/.gitignoreR7)

Temporary Authentication Change:

• Commented out password verification in authenticate_user (likely for development/demo purposes; this should be reverted before production). (mindtrace/apps/mindtrace/apps/poseidon/poseidon/backend/services/auth_service.py, mindtrace/apps/mindtrace/apps/poseidon/poseidon/backend/services/auth_service.pyL103-R104)

[canelbirlik]

let's remove this one

[uzairali19]

Done

[canelbirlik]

Thanks for the PR, I've left some comments on the individual parts and I'll test out the UI later, overall most immediate thing to do is hook it up with dataset and reflect the data models we have. That would guide the fields used in the UI side as well, right now we have unnecessary fields that are not in the db.
my suggestion on the strategy to integrate backend into this:

• Repository to interact with DB.

• Service calls repository with filters, scope queries by org_id, checks if user has acces to requested dynamic page.

• View Models: We could fetch the data only needed to display the table columns or accordion view, then upon selection/modal open, we could fetch the detailed data, i.e.:
  row_vm: data needed to display the table -> summary projection of the original table data
  modal_vm : data needed to display the modal

• Filterings are done on db calls (repo+service), UI displays the result as it is.

• loading spinner : within the refresh calls, we set is_loading to true or false and table to display a spinner

[canelbirlik]

also in case we want to render table in other pages, we might need table to have its own component state rather than a global one:
https://reflex.dev/docs/api-reference/componentstate/

[canelbirlik]

this file seems redundant, can we remove this and move this final page to filter_table.py ?

[uzairali19]

That would break the structure, since we are keeping pages separate from components. I think it's better to wrap page_container in the page file and have clarity in how we will use it, etc. Avoids confusion and is clear; we need to do that with other pages, too. I'll change the name and remove the demo.

[canelbirlik]

these many selected fields look crowded, same way we store a single rows, can we store a single details object?

also let's type rows and this, example:

@dataclass
class PartPreview:
... serial_ids, other preview info

@dataclass
class PartDetails:
images: List[str]
etc.

and then within the state:

self.rows:List[PartPreview]
self.selected_part_detail:PartDetail

this will be more safe, right now it's pretty hard to track what part details or what rows are