What happens when archiving a comment thread?
I see that the comment thread disappears from the file/commit, but is there an archive somewhere where it appears or is it just deleted?
Archived comments remain available via a query )Speckle hates deleting things) - but there isn’t a UI for them yet. This is still a quasi-experimental feature while we learn what users want to do with them.
To find them with the GraphQL explorer:
(The relevant flag here is archived: true)
{
comments(streamId: "YOUR_STREAM_ID", archived: true) {
items {
id
createdAt
resources {
resourceType
resourceId
}
rawText
}
}
}
This will give the comment text, and the correct commit/stream host for the comments.
1 Like
Okey, thanks! How can we find files atteched to archived comments?
In a sense, not where you might expect it within the query structure, but within the comment text body, there is a field attachments that can expand to the id and other file metadata. The id can then in turn be retrieved as a file from the server
{
comments(streamId: "YOUR_STREAM_ID") {
items {
id
text {
attachments {
id
fileName
}
}
}
}
}
I have a fuller explanation of this over here: GraphQL get attachment from comment - #2 by jonathon
Incidentally, as I was looking to expand this answer, you cannot get comments from a Stream or Commit query; to get comments from a specific commit - you can only return the number of comments.
Instead, you can apply a filter by resource to the comments query above.
If you refer back to the forum answer on attaching files API post comments with attached files - #7 by jonathon, comments are attached to a Stream resource; in this case, a Commit in this way, you can get just the comments filtered to this resource (both resourceType and Id are required):
{
comments(
streamId: "YOUR_STREAM_ID"
resources: [{resourceType: commit, resourceId: "YOUR_COMMIT_ID"}]
) {
items {
text {
attachments {
id
fileName
}
}
}
}
}
Great that gets the file, though is it also possible to get the rest of the comment thread (with further attachments), ie now I’m only getting the first comment in the thread (marked in image below)?
Edit: Also a question on archiving/deletion - what happens when deleting a stream, will the stream and all its data (ie files, comments, attachments on comments, etc) be deleted?
That’s a moment that delete means delete!
You can add replies to the comment items query
{
comments(streamId: "") {
items {
id
text {
attachments {
id
fileName
}
}
replies {
items {
id
text {
attachments {
id
fileName
}
}
}
}
}
}
1 Like
Oki great, and everything uploaded to/created on the stream (files, comments, attachments on comments etc) will be deleted to? Ie no longer available by query either?
Ahh great!
I’ll check with the team about files stored as they aren’t intrinsically linked to the stream’s Speckle objects.
Are you looking to ensure purging or trying to recover from an accident?
Okey thanks, I’m ensuring purging. Is archived stuff, comments, attachments on comments, etc deleted when deleting a stream as well?
Objects, Comments, Branches, and Commit data are all deleted when a Stream is deleted, including archived stuff.
Attachments are not by default. This will need to be done in code. Ideally, before stream deletion, you can retrieve the attachment details. There is a single endpoint, I believe, that will wipe all attachments with one call.
We haven’t yet built a full infrastructure around binary uploads as we have implemented them for comment attachments now, but theoretically, they could be reused multiple times across a Speckle server (as we look to support more things that utilise them, e.g. materials or textures)
Knowing that a “nuke” option should take these resources out is a helpful use case. We don’t currently support this OOTB as a single act. Associated with this should presumably be a “what’s in my storage” view, where resources could be managed directly…
I can give feedback to the team.
Sounds interesting, how could I do that? Can I use the attachment ids?
That would be really useful!
1 Like
Continuing in REST terminology
For individual attachments:
DELETE /api/stream/:streamId/blob/:blobId
We have an endpoint for deleting all blobs for a stream, but on inspection, it is not functional yet:
DELETE /api/stream/:streamId/blobs
Do you know anything more about this? 
Or if this is anywhere on your roadmap to be implemented?
Can you delete a file upload?
I tried deleting with
DELETE /api/stream/:streamId/blob/:blobId
which seems to work (when making a get request for it I get “The requested asset doesn’t exist”), though it is still available as a file, can I delete that?
I will check with the server team about this and report back. It sounds like it could be a cache issue…?
Hey @Sandra
I’ve tested your described workflow, and here are my findings:
- deleting the blob with the blob API does delete the blobs
- the file imports page still shows the imported file, which is intended, we should show all the versions (commits) that were created from a file import
- defore deleting the blob, the download returns the original
sourcefile - after deleting the blob, and this is what is probably confusing for you, because its semi broken, the download button doesn’t disappear from the list for the deleted blobs. And to make it a bit worse, it downloads a file, that has the same name and extension, as the original source file had. BUT the content of the file is not the original content. See below.
I’ve added a ticket for our server to track this issue:
1 Like
Okay I see, and the commit from the file should still exist (which it does) even if the file is deleted?
And the “fileUploads” will show the version history of uploaded files, same as on the “Import File” page? I get this response when I have uploaded and deleted one file on a stream:
"stream": {
"fileUploads": [
{
"id": "id",
"fileName": "fileName",
"fileType": "fileType"
}
],
"commits": {
"totalCount": 1,
"items": [
{
"id": "id"
}
]
},
"blobs": {
"totalCount": 0,
"items": []
}
}
You are correct. The file uploads track the created commits/versions from files and the blobs track the original source files.
Hope it makes sense now, our lingo is probably not perfect here. But we are bit by bit working on this
2 Likes
Great thanks, it makes sense
2 Likes