Open hampelm opened 10 years ago
How does this relate to organizations? Eg is it easier to just have an organization management interface?
What does "sharing" mean here? Is the second user a full owner/user for the survey? Or do they just have read rights (more relevant for private surveys)?
We probably want to have both. Some orgs won't want to share all surveys with everyone. But which is easier to implement first?
@prashtx Second user is a full owner.
We've discussed this before, but in implementing, there are a couple hangups that have me reconsidering the sharing strategy. I vote B, which is a shift from earlier, unless there's a more straightforward way to structure A.
A. Server-side
This is what we've discussed. We'd have a route like app.put('/api/surveys/:surveyId/users', users.ensureAuthenticated, users.ensureSurveyAccess, surveys.addUser); That would find a user and add them to the survey.
Pros: Simpler client-side implementation (nicer for consumers, including any future apps we make). Easier to test.
Cons: More complicated logic to maintain. How to handle removing users from surveys? We could issue a DEL with a body, but that seems messy.
B. Client-side
In this method, most of the work would happen client-side:
Pros: Less to add and test on the AP (just need to find users). Easy to remove users from a survey.
Cons: More verbose on the client. Harder to test.
PUT surveys/:id/users/name@example.org
DEL surveys/:id/users/name@example.org
Add an API to let survey owners share full access & ownership with another user.
Two scenarios: Sharee already has an account. Easy:
Sharee does not have an account. Harder: