willchen96 fixes the sharing bug that was hiding shared projects

A subtle database mismatch was breaking the exact feature collaboration depends on - and the same pass opens the door to self-hosted storage.

workflowinfrastructure

This pass fixed a real breakage and quietly widened where the project can store files. Two distinct changes:

  • Shared projects come back: anyone who had a project shared with them was hitting a hard failure when they tried to load their project list. The query that checks who a project is shared with was asking the database the wrong way. willchen96 corrected it in both places it mattered - the main list view and the internal permission check - so collaborators can actually see the work shared with them again.
  • Self-hosted storage becomes viable: the file-storage client was reconfigured to talk to storage services that don't follow Amazon's exact address format. That lets teams point the project at a local or self-hosted storage box instead of being locked to Amazon's cloud.
So what Anyone running this for a team - or weighing whether they can host it on their own infrastructure - should take note: collaboration works again, and the storage layer is no longer tied to AWS.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

1 commit from Open-Legal-Products/mike, oldest first. Source extracted verbatim from the harvested git log.

SHA Subject Author Date
625bca4d fix: handle JSONB shared_with filters and path-style S3 willchen96 2026-05-10 ↗ GitHub

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-715.md from inside the repo you want the changes in.

⬇ Download capture-thread-715.md