I run a video company. We have a project tracking template shared internally.
The template makes use of my frame.io Pack to pull in videos, review links, comments, etc. We always want to use the same Frame-io credentials (our general primary company account).
THE PROBLEM
Sometimes, the frame-io account requires reauthorization. I haven’t been able to determine the pattern; perhaps I need to just dig in on this problem, but I also feel like this just happens with OAuth sometimes (token expiry or something?) and is a part of life.
Re-authenticating is not hard, whatever. BUT.
It can only be completed by the person who created the doc (from the template) in the first place.
E.g…
- Ahmed creates a doc.
- There is no way for him to inherit the Pack account from the template (right? it would be nice if he could…)
- So on doc creation he needs to authenticate with Frame-io using a Packs account tied to his Coda account (even if he’s using same frame-io creds as everyone else)
- Later, Beatrice tries to sync videos, but the creds have failed
- The only way she can fix it is to add her own instance of the frame-io creds in a Packs account tied to her Coda account
- She can’t just do this in one place though; she has to do it on every table (and some tables only exist on hidden database pages, in my case)
This makes Ahmed, Beatrice, and the whole team very, very sad.
Anybody know how to make them happier?
IDEAS
One thing I was thinking was instead of having users create docs from the template in a normal Coda way, I could instead generate project management docs for them via API with a consistent doc owner. Not sure if I can automate the allocation of a Packs account from that doc owner, but if I can, that would at least mean that all docs in the workspace would rely on a single frame-io Packs account. If ever there was an auth issue, fixing that issue in one place would fix it for all the docs.
Another approach is just to create a private version of the Pack with system auth (can I do this with OAuth? not sure I’ve tried). This is currently my most promising solution, but sucks because
- Maintaining dual codebases is annoying and I’d like to keep supporting and growing the public version
- It doesn’t solve what I suspect may be a similar problem for other users