NSLS2 / NSLS2/nsls2api

Small mismatch in user info from /proposal vs /person

Open
#237 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
0
Forks
13
Avg merge
1h 17m
Merged PRs (30d)
1

Description

The "users" key in the /v1/proposal's response is not the same as the response in /person

For example: https://api.nsls2.bnl.gov/v1/proposal/320326
The users section in the url above has my user info:

{
  "first_name": "Venkateswaran",
  "last_name": "Shekar",
  "email": "vshekar1@bnl.gov",
  "bnl_id": "27196",
  "username": "vshekar1",
  "is_pi": false,
  "orcid": "0000-0001-5625-2475"
}

While the response in: https://api.nsls2.bnl.gov/v1/person/username/vshekar1

{
  "firstname": "Venkateswaran",
  "lastname": "Shekar",
  "email": "vshekar1@bnl.gov",
  "username": "vshekar1",
  "bnl_id": "27196",
  "bnl_employee": true,
  "institution": "Brookhaven National Laboratory",
  "orcid": null,
  "globus_username": null,
  "pass_unique_id": null,
  "account_locked": null,
  "cyber_agreement_signed": "2022-08-01T00:00:00",
  "facility_code": null,
  "facility_name": null,
  "citizenship": null
}

Would be good to standardize first_name + last_name key names in both responses. Additionally the orcid is not available in /v1/person. Finally if user "institution" is available in the proposal response, it would be really useful for the lambda project.

Happy to make a PR so address them

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the /v1/proposal/{id} and /v1/person/username/{username} entry points that produce the shown responses. Compare their user fields and determine the project’s intended naming and availability for first_name, last_name, orcid, and institution. Done means the related API responses consistently expose the agreed fields, with tests covering the changes.

Written by the indexing model from the issue text.

Assessment

Tech stack
fastapi, python
Domain
api, backend-api-design
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.