Able to lock self out / unlock other's files

Viewed 21

It seems like a bug where you can change your username while having a file unlocked, and it will lock you out, and conversely you can change your name to someone else's name and lock a file (and edit it while unlocked).

Maybe this is by design or would be overly complicated to fix and in the backlog because user authentication can be an annoying problem, but thought I'd log it.

Recreation steps - locking self out

  1. Unlock file as username example
  2. Change username to otherexample
  3. Return to file
  4. Unable to edit

Recreation steps - editing other user's files

  1. Signed in as username example and see file locked by username otherexample
  2. Change username to otherexample
  3. Return to file
  4. Can make changes and lock the file as if you are the other user
1 Answers

Thanks for the feedback again!
Yes! this this something I haven't fully decided, and open to suggestions.

The main 'issue' is that adding authentication, will introduce a new dependency for the users, either host a "drafft server" to manage permissions or require internet connection to log in to an auth provider for example. I feel a bit annoyed already for checking the license key at boot...

Another option, which is kind of a middleground, would be to hardcode the username to the email or name registered in the license key. this would also solve internal communications (I plan to add some sort of commenting/chat system when I sort what is the best way to handle this) with the benefit of no additional infrastructure needed. But this approach might be too limiting for the user (they won't be able to change it, or change the display name)

then, the traditional approach, hosting an 'admin' backend for this sort of stuff, and maybe hosting a "project" admin app for inviting/granting permissions, etc, but again, this would mess with the offline first approach...

tldr: this is a bit complicated due to the project vision and tech stack, but open to any suggestions!