Closed jibsamoun closed 11 months ago
Thanks. I'll work on this, it's pretty straightforward, no design work needed.
Just a redesign idea: for each user (new/existing users) we should generate a unique token to identify them. The token can be generalized by the order they create the account. for example, the first user has token 001 and the 10000th user has token 10000... Then we can redesign the collaboration page to add/remove collaborators by typing their user token
@willGG11 I'm unclear on why we need a token. Usernames are already unique. The page just doesn't support adding via them yet.
@willGG11 I'm unclear on why we need a token. Usernames are already unique. The page just doesn't support adding via them yet.
right now we can only add or remove collaborators by email. I am thinking instead of adding a feature that allows you to add/remove by username. Wouldn't it be easier to consider all users based on token (so we don't need to worry whether it is an email user or username user). Besides, I believe coming up with a unique easy-to-memize username is very time-consuming especially when there is no username recovery option. forgetting a username also leads to loss of account.
@willGG11 Yes, this issue is about adding and removing collaborators by username. (That's the point of this issue). How would having to memorize a randomly generated token be easier than remembering a username? I'm not sure I'm following we need another unique identifier when we already have one (email or username). Maybe you could walk me through your logic in more detail? I'm not seeing your rationale. (If your rationale is that usernames are unrecoverable, that's a problem with usernames, not a problem with adding/removing by username, and not what this issue is about).
@willGG11 Yes, this issue is about adding and removing collaborators by username. (That's the point of this issue). How would having to memorize a randomly generated token be easier than remembering a username? I'm not sure I'm following we need another unique identifier when we already have one (email or username). Maybe you could walk me through your logic in more detail? I'm not seeing your rationale. (If your rationale is that usernames are unrecoverable, that's a problem with usernames, not a problem with adding/removing by username, and not what this issue is about).
I guess you are right. It seems like I overlooked and kind of off the point because I am thinking about if there is a chance we don't have to use the unique username to create an account but I realized it doesn't make much sense.
We definitely have unique usernames. (That's the only way we can tie an account to a single password).
Your concerns about username/password accounts are absolutely valid, and a key known limitation in authentication circles. But that really is a separate issue, and a very tricky one to solve given federal law, risk of lawsuit, and school compliance practices (#305). This issue is all about adding the missing functionality of add/remove collaborator by username.
Expected behavior
When visiting the "Sharing" page of a Wordplay project, the "Collaborators" section should explicitly state that you can add/remove contributors via email OR username. The placeholder text for the invite box should also explicitly be labeled as "email/username".
Actual behavior
Summary
Screenshots
Environment
Desktop