/imports endpoint doesn’t return running imports

The /imports endpoint doesn’t return the currently running imports.

For context: When the dashboard uploads a new file it adds the id created for this file to a set of watched ids. If there are items in this set a polling mechanism is started that continuously polls the /imports endpoint in order to update the internal state of the dashboard with the current state of the imports. This happens so the dashboard can display the current phase (importing / normalizing) and progress to users. If the response to the poll requests doesn’t include the respective file id anymore, it is assumed that the import job for this file has finished and the id is removed from the set.

Reproduction:

• Login to the dashboard
• open the dev console in your browser
• upload a file the media section of the show’s basic data
• monitor the visible state of the upload in the ui and compare it to the output in the network panel and console

The job state in the ui will show Verarbeite (Processing) the entire time. This is the default a more specific state cannot be determined.

If you look at the network panel you should see something like this:

As you can see the imports response doesn’t contain any jobs even though an import job is running right now.

Consequently, the import watcher is stopped almost immediately because from it’s point of view there are no import jobs to monitor.

added bug label

assigned to @eigenwijsje

marked this issue as related to dashboard#342 (closed)

mentioned in issue dashboard#342 (closed)

changed milestone to %1.0-alpha6 — Wondrous Whale

added To Do label

added Cycle [1/25] label

added P1 label

@eigenwijsje please note that because of that bug, @kmohrf is blocked with proceeding on dashboard#342 (closed)

I have found the source of the problem.

If the request doesn’t include the showId (as above) and the requesting user is privileged (a program manager), the imports from public shows will be listed.

Otherwise, if the requesting user is not privileged, the imports for shows owned by the user are listed.

Therefore, if you are uploading files for a show that is not public and where you are not the owner, like the one above, then the imports won’t be listed for you.

For now, I’m making the shows public.

I suggest to either:

• add a checkbox to the dashboard and use steeerings API to set if a show is public, or,
• remove the Show.is_public field and list all the shows as "owned" by privileged users.

@kmohrf : what do you think about this?

added Doing label and removed To Do label

After some time to think about it, I lean towards removing is_public from the model.

This would mean that nothing changes for not-privileged users and that privileged users get to "own" all the shows.

And, obviously there would be no publicShowsIds in the OIDC scope claims.

This sounds reasonable and is what I have expected. One thought though: This is only about the import jobs which in and of themselves don’t expose any confidential data. Other endpoints like steering’s /shows usually expose all data when not filtered by any queries. Is there a reason why we think of import jobs as restricted data?

• Remove is_public from the model: @eigenwijsje please remind me what this field is for? Afair it's only used by Helsinki and to enable/disable shows via the button, we use is_active. Is that correct? In that case I have no thoughts on this

• Make import job details public: If there is no sensitive data usable for attack vectors, I'd vote for removing any required auth, as it makes the code more simple and goes well with our "open data rule of thumb". What do you think @kmohrf and @eigenwijsje?

is_public was introduced Christian in 2000. The merge request explained "This adds a flag to Shows that make them "Public". Tank uses this information to allow access and use of files and playlists from this show to any user. To upload/edit/delete files and add/edit/delete playlists of this show you still need to be a owner.".

Until I clear with Christian if this is really necessary, specially now that only the files are stored in tank, I’ll simplify the access to /imports to list all running imports to authenticated requests.

added discuss label

Calling /imports now lists all the imports running.

http -a $TOKEN -A bearer aura.local/tank/api/v1/imports

The requesting user is not jacinto+ and only gets a response with a valid token.

{
    "results": [
        {
            "created": "2025-01-29T14:33:11-04:00",
            "id": 20,
            "progress": {
                "progress": 0.75933886,
                "step": "fetching"
            },
            "show": 1,
            "source": "upload://05%2520-%2520Over%2520The%2520Hills%2520And%2520Far%2520Away%2520(Live).mp3",
            "started": "2025-01-29T14:33:11-04:00",
            "state": "running",
            "user": "jacinto+"
        }
    ]
}

Actually, I don’t think this is sensitive information and/or can be used for an attack. But I’m no expert in this.

Thank you for the quick solution, this really looks fine!

added ready-for-testing label and removed Doing label

closed

removed ready-for-testing label

removed discuss label