Open hamishwp opened 10 months ago
For point 2, we also need to build in the ability for users to insert external database tokens and their usernames that can be used to allow the user to also extract data from non-open access database
Can you say more? Do you mean the user needs to be able to store their access credentials for an external database, that would then be used to query that external database on the fly? We can encode some idea of access rights or permissions into the token, but encoding usernames and credentials to external databases seems a bit non-standard - would be good to understand the use-case better.
@justinginnetti @LukeCaley @hamishwp (cc @tovari):
Here are 3 directions we can take with the terms & conditions on the GO website accounting the current UX:
Scenario 1 - “Forced acceptance of the terms” For anyone landing on the website, there would be a popup to ask them to accept the conditions. It would then save the acceptance into cookies. We could also potentially save them to user's profile once or if they login. This is a forced user flow, as users have to make a choice before proceeding to the website. Cons: users are usually reluctant to accept terms online, especially without fully understanding what they are. It also may be a strange experience if they don't accept, since they will technically still be able to browse the platform, but without seeing certain datasets.
Scenario 2 - “Soft acceptance of the terms” Not forcing the user to go through the popup, but having a cookie-style banner for users to accept or not. They can still browse the website, but until they accept they won’t see the datasets and the banner will persistently stay. Cons: same issues as above regarding not showing datasets if they reject, while they may not fully grasp the idea. The users tend to reject things online if possible.
Scenario 3 - “Auto-acceptance of the terms” No action is needed from the user. Just a notification that just by using the site they accept the terms. If they don’t want, they need to leave the site. Cons: The users don't have a say in it. They are sort of forced into accepting the terms by using the tool. This may be acceptable if the terms are not so restrictive or require their personal data.
Unless we need an explicit consent, the third option is the best and least invasive. The banner will be treated like the cookie banner, meaning it will be stored in user cookies and may reappear only if the users clear they cookies or load the site for the first time.
We can, in addition, expose further terms and condition regulations to registered users, especially given that they get access to more and more sensitive data. As such, we will need a checkbox upon registration that the users must accept to register. The link to terms will lead to another page with the actual content.
We shall also have a more permanent link to that terms page in the footer of the platform.
Okay, thanks, @mariam-yu . I also prefer Option 3, plus the "checkbox upon registration" for new users that you proposed above.
JWT token integration with Montandon
discussion here6th Feb Meeting Summary
Initial clarification: acceptance of the T&Cs is not required unless:
What we need to build is the following:
For the 5th point, I propose the following: create a survey (inside GO if possible) that allows an external user to sign up for a Monty API key, then, once we have approved it, we send them the API key to the email address they signed up with.
Thank youuu!
@samshara @frozenhelium @udaynwa @mariam-yu @batpad @tovari @nnjemie
We need:
For point 2, we also need to build in the ability for users to insert external database tokens and their usernames that can be used to allow the user to also extract data from non-open access database (such as EM-DAT). However, need to be careful about storing these tokens...