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.
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/inforesponse is already the natural place for this information. I addeddisplay_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/inforesponse, extractdisplay_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_intcould be refractored into sth more generic likerdms_version_intoreln_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.