Repository navigation
ULIMS Integration for Visit Directories #388
Description
Part of #373 Backend Integration/ Experiment Manifest / Post Collection Tagging/ Pocessed Data
Automatically resolve and propagate the active visit directory via ULIMS, removing the need for manual text-field input on each screen
Goals
Acceptance criteria : What journeys should the user be able to complete to consider your feature done
Be as specific as you can, check them off once they work. Add more if you find more requirements during development. Issue should only be considered done after all of them are checked
- Zero-Manual Visit Input: The active visit directory resolves automatically behind the scenes and maps data storage paths without user configuration.
Tasks
base on the goals, deduce the tasks required. check them off once they're done
- Dynamic Directory Hook: Resolve active visit details and propagate them to the active file writer and workflow.
- This is effectively done via supergraph see
Activity
[-]Integrate ULIMS to automatically resolve current visit directories across all screens.[/-][+]ULIMS Integration for Visit Directories[/+]NKatti2011 commentedon Sep 16, 2026
Included notes from @EmsArnold.
apps/visr/src/routes/Dashboard.tsxRelm-Arrowny commentedon Sep 16, 2026
Surely this must be linked to authorisation how does VISR work out what session I am allow to have?
EmsArnold commentedon Sep 16, 2026
ViSR is a special case but a good example is the waffle project on I15-1. The UI can query the supergraph with the users access token, and the Session Service will only provide those instrument sessions which the user has access to see. Further you can filter this so only "In Progress" sessions are returned. This would essentially give you what you require - with the caveat that if a user has two active sessions on the same instrument at the same time, it would return both (think about beamline staff who have access to both commissioning and user sessions). You would still need a mechanism to select between multiple sessions, though the vast majority of users would only have the one.
Relm-Arrowny commentedon Sep 16, 2026
Moving this to ready I think we have enough to make this. One question, is this session service going to change? I assume we just hocking onto existing dimaond session service.
EmsArnold commentedon Sep 16, 2026
N.B. easy integration with supgergraph will be slowed down by the current changes to make the supergraph public. This is currently blocking this PR to set up a reusable relay environment for your graphql queries. If this is also blocking here, please let us know and we can try and prioritise this work (there's a slack channel called
the-graphwhich is a good point of contact).The session service should not change (any more than any of the other services will be changing). As it stands, there is active development occurring in all of the subgraphs available (session service, samples, experiments, containers, and workflows), as well as active development of the supergraph itself. Any significant changes should be noted in the slack channel in good time, but may require you to alter queries you're using should they be breaking. Ideally there will be a minimum number of breaking changes in the future.
The session service is part of the new D-II architecture (along with workflows and ULIMS), though it provides data that many systems currently retrieve from UAS/iSpyB/syncweb.