Support creating shares without email address and add an option to send invitations to arbitrary email addresses

[PhrozenByte]

⚠️ This issue respects the following points: ⚠️

• [X] I agree to follow Nextcloud's Code of Conduct.

Describe the goal you'd like to achieve

~~As a poll owner, I want to be able to share a poll with groups of people instead of just individuals.~~

As a poll owner I want to explicitly invite multiple external people to a poll via email but let them act as the same poll user, because a workaround I use is time consuming and error prone.

Describe possible solutions

I need this on a regular basis to allow groups of people (no Nextcloud users) to self-assign appointments within given time periods. Since I want at most one appointment per group (not per individual), I can't use regular (user/email) shares. Creating a public link share per group doesn't work either, because I'd definitely end up seeing multiple participations per group. My current solution is to create an email share with a fake email address per group and share the URL with all members of that group separately.

My initial idea was to "group" multiple shares together, i.e. to sync the answers of multiple shares (i.e. if person A selects option 1, it is also selected for person B, and vice versa). However, thinking about it, it's probably a little over-engineered... :see_no_evil:

Thus I'd like to propose extending email shares to not just accept exactly one email address, but an arbitrary number of email addresses, including no email address at all. Creating a share with the following input should all be valid:

1. Team A
2. Team B [email protected]
3. Team C [email protected] [email protected]

Internally variant 1 creates an external share without email address, variant 2 creates a regular email share as of today, variant 3 creates two shares of a new type (type redirect?) that doesn't allow participation on its own, but redirects to the same external share without email address.

Since we're sharing with a group of people instead of individuals, we don't want to store an email address. Furthermore we don't want to allow participants to change the name. Thus we must hide the "Register" card (i.e. the dialogue to change name and email address). For variant 1 and 3 this is the only meaningful behaviour, for variant 2 it should be an option (since we don't distinguish between regular email shares and sharing with a group of users with a single email address).

Additional context

No response

[dartcafe]

This can be achieved using the contacts app and contact groups.

[dartcafe]

I read your request multiple times but am still not sure if I understood your use case correctly.

• The sharing system relies on the precondition, that one share refers to exactly one user. Therefore multiple email addresses are not possible in one share.
• An external share without email address can be made possible. At the moment it is not.
• However, a user of an external share can change his name and email address when ever he wants.

All in all, this looks like an edge case to me; expensive with limited value.

BTW: My last answer was to fast, because of the short user story:

As a poll owner, I want to be able to share a poll with groups of people instead of just individuals.

[PhrozenByte]

This suggestion isn't really about changing that "one share refers to exactly one user", it's more about changing what an user is. Right now an user must be an individual, i.e. a single person that gives a single answer to a poll (i.e. participates). Basically 1 person : 1 user : 1 answer. My suggestion is to allow that an user can also be a group of individuals. The relation between user and answer doesn't change, but what an user is, basically n persons : 1 user : 1 answer.

You might remember #3099 in which I explained that I use polls for group/team forming. As soon as the groups/teams are formed, I often need to poll the teams (not the individuals!), e.g. that they self-assign appointments within given time periods. It's up to the teams to decide what answer they want to give. My current solution is to create an email share with a fake email address (e.g. "Team A [email protected]") and share the URL of that share with all members of that group separately.

[dartcafe]

My suggestion is to allow that an user can also be a group of individuals.

A share does need a username and optionally can have ONE mail address. This is how it is designed.

1 person : 1 user : 1 answer.

Polls does not know anything about persons. If one user uses the share access or multiple is out of Poll's view. This is where you step in with your workaround.

Breaking up the current logic with multiple email addresses per share is a huge work. Multiple parts of the code have to be changed, the error handling has do be extended and least but not least, we need a good UX for assisting in understanding and managing of the options. Talking about options: Quite a few options have to be added.

And still the value is limited compared to the cost. I fear you have to stay with your workaround.

[PhrozenByte]

Hmm... Please stay with me, I'm struggling to explain what I mean, thus I feel like that we talk cross-purpose. Sorry about that, it's my bad that I fail to explain it properly.

A share does need a username and optionally can have ONE mail address. This is how it is designed.

I don't want to change that. I rather suggest adding a new type of share similar to public: public shares don't represent a poll participant on its own, but rather trigger creating an arbitrary number of external shares, which in turn represent poll participants.

I suggest doing something very similar: When creating a share with input "Team C [email protected] [email protected]", polls creates three shares:

• One external share with a random token, random user_id, display_name "Team C", empty email_address, and misc_settings {"register":false}. This share behaves just like any other external share, the only difference is that misc_settings {"register":false} causes polls to hide the "Register" card.

• Two redirect shares with a random token, user_id matching that of the external share suffixed by _ and a random string, display_name "Team C", and email_address "[email protected]" resp. "[email protected]". Shares of type redirect behave very similar to a public share: When a redirect share is requested, its request is intercepted and redirected to the matching external share (utilizing the first half of the redirect share's user_id matching the user_id of the external share). The redirect share itself doesn't represent a poll participant on its own, just like a public share.

Regarding the UI I don't think that it requires major changes: None of the three shares are treated any special, all three shares show up as regular shares with their respective icons. The relationship between the external share and the redirect shares is shown by having the same display_name. Optionally, it can be further emphasized by sorting them after one another. The only functional difference is what happens if one deletes the external share: This must also delete the matching redirect shares. Thus it might be considerable to create a new share type that is otherwise identical to external, but that's an implementation detail. Deleting one of the redirect shares yields no special treatment. Another probably meaningful, but really optional UI change is to add an option to the UI to change the register option in misc_settings of an external share.

[dartcafe]

Nono. I think I understood you, but referencing your last explanation: What are the 'referencing' shares for. You could simply send the link of the share, the references target to, to the team members. You would get the same result, excactly as with your workaround.

The only thing you will win is that you don't have to send the link to the actual accessing share manually.

[dartcafe]

The only thing you will win is that you don't have to send the link to the actual accessing share manually.

If this is what we want to win, it could be much more simplier solution to allow a share creation without email address and add an option to send a share to other email addresses.

[PhrozenByte]

If this is what we want to win, it could be much more simplier solution to allow a share creation without email address and add an option so send a share to other email addresses.

Wow, I was so focused on the "sync answers of multiple shares" approach that I didn't even spare a single thought about that :laughing: You're absolutely right! A totally different, yet way simpler approach and it solves the exact same problem. Great idea! :+1:

[dartcafe]

This is why I am a big fan of user stories. But they are more complicated to write then as it looks like.

Allow me to switch into the coaching role:

You wrote:

As a poll owner, I want to be able to share a poll with groups of people instead of just individuals.

Easy. This is possible. Use a group share 😉

But what you wanted to write was:

As a poll owner I want to explicitly invite multiple external people to a poll via email but let them act as the same poll user, because a workaround I use is time consuming and error prone.

The user story helps to focus on the goal (I want [to achieve] ...) and the value (because). The "how" is explicitly out of focus.

Mostly people want to achieve a goal and then try to find a solution. When they found one, they continue focussing on the solution and explain it in all details but forget to talk about their initial goal. Especially when they are in the same business, because they know what they are talking about.

I know how Polls works (at least for the most parts of it 🤣) and when we are talking about complexity.

Beeing aware of this, I try to get the focus back to the goal, by questioning everything until I believe to understand the initial goal. And of course I want to minimize the costs (aka work).

But I am happy this discussion led to a more maintainable approach.

[PhrozenByte]

This is why I am a big fan of user stories. But they are more complicated to write then as it looks like.

True that :smile:

Your user stories fits perfectly :+1:

But I am happy this discussion led to a more maintainable approach.

Thanks :heart:

---

Some more thoughts:

Assuming polls just allows sending poll invitations to arbitrary email addresses and doesn't even store these email addresses, some comfort features like reminder emails don't work. Whether it's feasible to support these comfort features from the start, or something for the backlog, should probably depend on the work required. Your take.

Another nice-to-have (yet IMHO more important) feature is allowing to disable the "Register" dialogue / hide the "Register" card for such shares. I know that this has been discussed multiple times before (AFAIR at least...) and was rejected for good reasons, but the assessment changes with this addition: If I invite groups of people, I really don't want the individuals to change the group's name, or email address. Yes, it kinda sounds silly that people change these values, but they do - even with a bold "Don't change these values" disclaimer in the poll description. In fact, it happened just yesterday - one of the reason why I opened this PR yesterday. But I guess you already assumed that since you correctly noted "because a workaround I use is […] error prone" :see_no_evil: :smile: