Replies: 2 comments 3 replies
-
|
Thank you for picking up this topic and putting thought into a concrete proposal! That said, I think this approach wouldn't solve my particular use case. The guest login still requires knowing the friend's email upfront, which is often the actual blocker: either I don't have their email address, or they simply aren't ready to join a group yet. What I think is actually missing is the ability to create a placeholder member by name only — add them to a group, start recording expenses involving them, and then link that placeholder to a real account or email later, once the friend decides to join. To be clear: I don't see the signup itself as the problem, and I'm not looking for a way to give unauthenticated users access to the app. What I need is a way to track expenses involving someone even when their email is unknown or they haven't registered yet, with the option to connect their real account retroactively. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for picking this up. I actually like the idea of having a guest account option to access the group, but I am not sure I understood exactly how your proposal works for the guest user. Would he still need to type his mail? I would like to have a way to smoothen out the process for the guest user, by not having them interact with their (probably gibberish) email. Ideally, the flow would look something like this:
This way, there would be no need for a (visible) "guest" option in the login screen, but the actual implementation still uses "authenticated" users. Ideally, this "authenticated" (not really, just technically) user could then use features such as profile pictures. In a perfect world, such a guest user could then (within the guest users account settings in the app, or like originally suggested by @krokosik as a screen before accessing the group) offer an option to actually sign up, at this moment changing the email address to their real one. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Numerous issues have been raised, trying to address the core problem:
I understand the sentiment and also experience the friction of requiring my friends to do signups (and their utter reluctance to do so), but approaches proposed in issues like #667, #67, #685 are not thought out enough. Crucially, in contrast to apps like
Spliiit, SplitPro is built around users having accounts and removing the email and account part, would raise several issues around scoping the permissions, edits, tracking activities etc. Linking accounts is also based on emails. The proposed solutions do not actually have a concrete plan to solve the technical limitation, stating for example:Without proposing how to actually implement that. As a cookie? That's very ephemeral, and I would actually prefer to have some sort of guest/anonymous account flow, in line with SplitPro semantics.
Current behavior
It is possible to have
dummyusers, by using theAdd to SplitProbutton after inputting an email. This actually creates a dummy account that then integrates with all the SP functionality, but the owner of said email still has to do sign up flow (with this exact email) to actually access the app.Proposal
Emails would still be required, but no extra verification will be performed:
The signup would thus become optional to users who want a greater degree of control . This is of course a security concern so this guest option would be off by default and togglable via an env var. The guest users would also have limited access to the app, without being able to create groups, sending invite links and most buttons in the account page. They also shouldn't be able to edit group members and group options.
I welcome any feedback on this approach, especially whether that would satisfy the aforementioned calls to solve this:
@Ziesie1
@phisch33
@Quadrubo
Beta Was this translation helpful? Give feedback.
All reactions