Display active models in sidebar of session viewer

[MoritzWeber0]

Parallel working on the same model can lead to conflicts, especially with the Git workflow. Right now, there are often chats in Teams where all team members communicate on which elements they are currently working on. However, chats are sometimes unreliable because they are not always read.
The workflow can be integrated in the Collaboration Manager directly.

For a persistent Capella session, we should identify all open models in the workspace. It would be great if we can also identify open elements.

All other team members should then see during the session creation and in a sidebar of the session viewer who is currently working on the same models / elements.

This should prevent that people work on the same elements at the same time accidentally. In addition, the feature could be used in the future to allocate session costs to specific projects.

[MoritzWeber0]

Identification of open models and elements can be implemented by listening to file events in the Capella session. It needs a bit of reverse engineering.

If you want to implement the "backend"-service in the Capella session, get in touch with me. I can provide more information.

[romeonicholas]

UI thoughts:

I'd prioritize having an explicit section at the top for elements that would be at risk of merge errors--this would ideally appear for everyone who either opens an element that already has staged changes, or who already has an element open when another user stages/pushes changes. The user could then open a modal from that entry in the sidebar that shows who else has the element open and display the diff viewer Viktor shared to determine whether they needed to take action (either pulling the changes to move the element out of the at-risk section or figuring out their merge conflicts before they get worse).

The section for all open elements should be similar. If we have log data on who is in read-only mode, that would also be helpful since we could remove them entirely from this list since there'd be no risk of them generating conflicts.

I left user off of the sidebar because I think that's only essential information when a conflict is possible/has happened and might seem a little excessive outside of that scenario, and I only use the specific element file name because the path would likely be too hard to fit (but maybe it would make sense to add to the modal).

Maybe we should have another call to talk about how this might be implemented since it would impact what information we have or when we can show it (e.g. would this be a WebSocket driven situation or is the data only up-to-date on page load?), and to see if there's any other important information I'm not considering in the side bar.

[romeonicholas]

Discussed with Moritz:

• At risk open elements should be at risk open models and display all open elements in that model (because changes in one element can actually impact others)
• Name is important to add at element level in sidebar

Next steps: before going further with frontend I'll start exploring Capella with a local install and seeing what kinds of messages Eclipse plugins can expose, since that will dictate what we can show anyway.

[MoritzWeber0]

@romeonicholas Due to limited progress in the development of the Capella plugin and due to many open other issues, @romeonicholas will focus on other tasks.

@jamilraichouni and I will discuss how to further address this issue.

[MoritzWeber0]

The issue will be on hold and will be further processed after the 5th of February by @jamilraichouni.

The initial goal is to inject a small Capella/Eclipse plugin into a session, which can identify changes of selected elements and communicate that to a server via HTTP. Alternatively, this could be realized with an internal timer, which checks every 0.5 seconds for the currently selected element.

If this turns out to be impossible, is would be good to receive the currently selected element per request.

[MoritzWeber0]

@jamilraichouni had some success with the development of a Capella addon.

My proposal for the interface would be:

import requests

requests.post(
    f"{api_url}/sessions/{session_id}/activity",
    json={
        "selected": [
            {
                "model": {
                    "uuid": f"{uuid_of_model}",
                    "path": f"{path_to_model_relative_to_workspace}",
                },
                "elements": [{
                    "uuid": f"{uuid_of_element}",
                    "name": f"{name_of_selected_element}",
                }],
            }
        ]
    },
)

[jamilraichouni]

@MoritzWeber0 , let us continue with the broadcasting of (a) selected element(s) here:
DSD-DBS/capella-addons#1