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?
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.
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
}
}
}
}
}
}
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!
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:
source
fileI’ve added a ticket for our server to track this issue:
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
Great thanks, it makes sense