GigaDB username and login

[only1chunts]

background

There are a number of tickets related to affiliate login and single sign-on and user account administration, all of which need to be looked at and aligned. To add to these we also have a concern over the "username" field in the database USER table, it is immutable via the GigaDB admin pages which causes confusion when the "email-address" is updated, ie. it means the username and email-address no longer match in the database. Related tickets include:

64

826

560

561

553

407

User story

As a user
I want to be able to select/define/update my own username in GigaDB So that I can use something that is not my email address (which is liable to change over time)

Acceptance criteria

Given I am creating a GigaDB user account When I am asked to add my details Then I also need to add a unique username

Given I am creating a GigaDB user account When I try to use a username that already exists in GigaDB Then I am invited to either login with that username or create a different username

Given I already have a GigaDB user account When I Edit my user profile (http://gigadb.org/user/view_profile) Then I am able to edit my username (as well as all the other details currently editable; name, email, affiliation, prefered linkouts and mailing list preference)

Additional Info

There are several stages:

1. Build a new yii2 application for managing user account
2. Ensure sessions created by that app can be used in other GigaScience applications, starting with GigaReview
3. Ensure sessions created by that app can be used in the main GigaDB website

Product Backlog Item Ready Checklist

• [ ] Business value is clearly articulated
• [ ] Item is understood enough by the IT team so it can make an informed decision as to whether it can complete this item
• [ ] Dependencies are identified and no external dependencies would block this item from being completed
• [ ] At the time of the scheduled sprint, the IT team has the appropriate composition to complete this item
• [ ] This item is estimated and small enough to comfortably be completed in one sprint
• [ ] Acceptance criteria are clear and testable
• [ ] Performance criteria, if any, are defined and testable
• [ ] The Scrum team understands how to demonstrate this item at the sprint review

Product Backlog Item Done Checklist

• [ ] Item(s) in increment pass all Acceptance Criteria
• [ ] Code is refactored to best practices and coding standards
• [ ] Documentation is updated as needed
• [ ] Data security has not been compromised (with particular reference to the personal information we hold in GigaDB)
• [ ] No deviation from the team technology stack and software architecture has been introduced
• [ ] The product is in a releasable state (i.e. the increment has not broken anything)

[rija]

Gigadb Authentication mechanism wasn't implemented following conventions and industry patterns. And as we rebuild the platform, we also need to move more to authentication service for our different future applications. In addition, we need to provide a deep integration of ORCID while providing some facilities for affiliate login when it make sense.

However this is epic size work, and cannot be done at once. We need to start with the basics and this story is very canditate as a first step.

It's difficult to implement that in the existing cocdebase given it idiosyncracies and legacy aspect. So it's opportunity to implemewnt a new authentication endpoint as a new Yii2 project, which has of the benfit of providing the functionalities of this stories out of the box.

We just need to adjust table names, and tests. We deploy that endpoint in parallel to existing mechanism and have all of us test us and when we (the all of us we) think it 's working smoothly, we can decommission the old mechanism.