display collaborators in DataHub Sync view

[Thyra]

and provide a direct link to manage them on GitLab (see nfdi4plants/DataHUB#60 )

[Copilot]

Pull request overview

Adds collaborator visibility to the DataHUB Sync view, including a quick link to GitLab’s project members management page, to support the workflow described in DataHUB issue #60.

Changes:

• Fetch GitLab project members for the currently selected remote and display them in a table with access levels.
• Add UI actions to refresh the collaborator list and open the GitLab “Project members” page.
• Document the feature in the changelog.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 6 comments.

File	Description
packages/renderer/src/views/GitSyncView.vue	Adds collaborator loading/parsing logic plus UI (table, refresh, “Manage in GitLab” link).
packages/main/src/DataHubService.ts	Adds an IPC handler to fetch project members from the GitLab API.
CHANGELOG.md	Notes the new collaborators display + management link feature.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Thyra]

All done :-)

[Brilator]

Tested on macOS.

• There's always a – not annoying, but tiny – lag when opening the DataHUB Sync view until the Collaborators widget pops up.
• if possible, would be good to present how members receive access (e.g. inheritance from group)
• might want to replace "Manage in GitLab" with "DataHUB"

[Thyra]

1. The delay is mostly because we're refreshing/checking collaborators through the API when a remote is selected, and it currently checks for updates on every remote before selecting the top remote which can take a lot of time, especially if you have multiple remotes:
   

   ARCitect/packages/renderer/src/views/GitSyncView.vue

   Lines 354 to 359 in c32da64

   	const init = async()=>{
   	await GitService.parse_status();
   	await GitService.get_remotes();
   	await GitService.check_remotes();
   	iProps.remote = Object.keys(GitService._.remotes)[0];
   	};

   
   I have switched this around so it selects the top one first and only then starts checking for updates, so the delay should be much shorter now (it's an API call so there will always be one but it has a spinner indicating that it's loading).
2. I can find out if membership is direct or inherited with one additional API call (one with "all" members and one with only direct members, then find the set differences) but the API doesn't tell me where the inheritance comes from, perhaps because it would otherwise allow me to explore memberships of groups I don't have access to. So I don't know how helpful a simple "direct vs. inherited" column would be? The full info is anyway just one click away ("Manage on the DataHUB" 😉)
3. Done :-)