Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separating user identitiy profile from author affiliations #165

Open
HannahSonntag opened this issue Nov 26, 2020 · 2 comments
Open

Separating user identitiy profile from author affiliations #165

HannahSonntag opened this issue Nov 26, 2020 · 2 comments
Assignees

Comments

@HannahSonntag
Copy link
Collaborator

We want to separate the user profile from affiliations. Currently its all in one table.

Similar ‘ideas’ can be found in switch EDU-ID and ‘PURE’ from Elsevier- we can use as orientation.

More details on this will follow once we hammered out the details. This is the token issue for now.

@HannahSonntag
Copy link
Collaborator Author

From our call with Robin/Orlin/Thomas/Steve/Hannah on 2nd Dec 2020
This is the suggested new database structure:

SDash_PDM_v1.0.pdf

In brief here are bulletpoints of the discussion we had: 

  • Overall the structure should be kept as simple possible and as complex as necessary.
    - Organizations (as in Affiliation); 
    i) Organizations would be user managed. Autosuggest could help avoiding the creation of duplicates. It could also be worthwhile to check out existing databases with lists of organizations that allow download or API-query (ror.org for example)
    ii) Do we need organization type? No
    iii) Organisation units; For sdash it would be sufficient to just have organization unit as field in the organizations table. But we should keep the organization unit table for the future since there is no harm in it 
  • Shall we include Middlenames? Yes, lets include Firstname, Middlenames, Lastname
  • Where do we keep email addresses – It is a bit tricky because these are used for authentication. And are also important for the external author identification and therefore part of the affiliation? Also institutional email address could change. This is still not quite clear to me which table will get which email address for what reason.
  • There was the question if we should keep linked in and twitter information separate in the table? - What Orlin suggested (sorry I cannot reproduce this. We went with Orlins suggestion) 

Will probably start on this after 'public page light' is implemented since we dont want to delay that any further.

@HannahSonntag
Copy link
Collaborator Author

We concluded that since it is too time consuming to refactor the database, that we will just not do it for now.
It is probably not worthwhile to go through all these changes as it is almost like rewriting everything.
But we are hoping that we can anyways extend the contract for another two month and use this time to work on ‘finishing the public page’, instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants