IS: Risk of share link confusion leading to incorrect rights and/or links not working

[BeccaMelhuish]

What is the problem?
It seems that the way our URL generation works could be confusing for any admins who are wanted to use share links for different levels of rights. This was to some extent backed up by a user insight in my latest user test.

It seems quite feasible that this could happen:

• An admin first creates a share link to invite participants, and shares it on their social media
• The admin (or even a different one who isn't aware a link has already been created) then wants to invite some admins via a share link too
• They do this by selecting the admin dropdown and copying the same link (which isn't changed when the rights are changed)
• Now, anyone who follows the link shared on social media will have admin rights

To prevent this they could create a new link when setting admin rights (if they think to do this, which seems relatively unlikely anyway), but this would mean the link they shared on social media would no longer work.

Why is this a problem?

• Risk of giving those intended to have participant rights admin rights
• Not possible to simultaneously have a participant share link and and admin share link (and an editor one, though this is less commonly used
• (Related to the above:) Issue of having to make a link inactive when it is still meant to be active
• No way for admins to see what links other admins have already created and shared

In tests it seems quite common that people share with participants via link and admins via email, but we can't assume this will always be the case, and my latest tester gave the impression she'd use a share link for both.

Possible solution.
Needs some thinking through from DUX :)
@kevincrepin @Lidziya-p @TiinaDUX

Will mark as high priority as it does seem rather high risk for rights mix-ups, which could be quite serious. Especially for groups, where having admin rights gives access to email addresses.

[kevincrepin]

This solution would be dependant on being able to generate multiple share links to one topic, and have different roles tied to those share links.

We could approach this so that the admin can add up to 3 different "user-role sharing links":

If admin now adds another one, in order to share a link that gives editor rights (for example):

Note that once another "section" is added, the role that is already in use will be disabled.

Since we have 3 different roles there can be up to 3 different "sections:

I also added tooltips to each role, just to give an opportunity what rights these roles have.

[BeccaMelhuish]

@kevincrepin I think this is good, but looking at it here I've thought of something that may simplify it for users a bit, and leave even less room for error :)

I don't believe we actually need to have a QR code available for all levels of rights. I've only ever seen users in tests use them for sharing with participants, and can't think of any use case where they would need to use them for admin or editor rights, as QR codes are always used in public contexts, e.g. a physical poster.

So, perhaps in this case we can automatically generate 3 URLs and 1 QR code for all topics. When an admin goes to this tab, all 4 of these things are already there for them, clearly set out with their rights next to them, and all the admin has to do is copy and share whichever one is relevant. (Unless they want to make an existing link inactive and replace it with a new one for some reason, in which case they would still have the 'regenerate' button from the current live version).

Wdyt? :)

[kevincrepin]

Ah yes, that's also an (easier) option :D

[BeccaMelhuish]

Beautiful, thank you @kevincrepin!

Dev task:
As per design above but for groups as well. In which case the copy will be 'Sharing to members' and 'Sharing to admins'. (No editors for groups). And the word 'topic' in the copy will always be 'group'.

Will assign myself to check the rest of the copy too, but development can be done base on what Kevin proposed above.

[ilmartyrk]

Estimate 12h - Needs a database update for the join links, also new tests. Also need to update the join link reading endpoints.

FE side should be quite simple 1h