OpenCloning / OpenCloning/OpenCloning_frontend
Read `display_name` from `/api/v2/info` to support generic RDMS/ELN-LIMS labeling in the UI
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 4
- Forks
- 10
- Avg merge
- 11d 9h
- Merged PRs (30d)
- 3
Description
Hi Manu,
The frontend currently hardcodes the string "eLabFTW" as the RDMS/ELN source name in several places: the source selector label, version check error messages, and connection error strings. This makes it difficult for alternative backends (see issue #667) to present their own identity and track sample source provenance in the UI without patching the built JavaScript.
The /api/v2/info response is already the natural place for this information. I added display_name: "openBIS LIMS" to the response from my openBIS adapter, but OC ignores it and still shows "eLabFTW" everywhere.
Proposed change
When OC reads the /api/v2/info response, extract display_name (falling back to "eLabFTW" if absent for backwards compatibility) and use it wherever the source name appears in the UI: the source selector, error messages like "Could not retrieve [NAME] version", and connection errors.
The info response could look like:
{
"elabftw_version_int": 40000,
"display_name": "openBIS LIMS",
"adapter_type": "opencloning-adapter-v1"
}
This is a small, self-contained change that immediately makes the generic backend experience much cleaner. Combined with the relative-path fix (separate issue) and the broader proposal in #667, it would allow alternative LIMS/ELN backends to integrate without any frontend modifications. Eventually variable names like elabftw_version_int could be refractored into sth more generic like rdms_version_int or eln_version_int.
Context
This came up while building an openBIS adapter for OC deployed on RRP. The current workaround is patching the minified JS at build time to replace "eLabFTW" strings, which is obviously not a good long-term solution.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating the frontend code that reads /api/v2/info and the hardcoded "eLabFTW" strings used by the source selector, version errors, and connection errors. Verify that display_name is used in each location, with the legacy name as the fallback, and confirm the UI shows the backend-provided name.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- api, frontend
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100