Clarify Viewpoint DELETE call

[Noushed]

We have introduced Delete Viewpoint call in v2.2, but there is no clear documentation regarding the associated comment of that deleted Viewpoint. We need clarification for the followings:

1. Modification time of the Topic should be updated upon DELETE viewpoint
2. Should we remove the viewpoint reference from the associated comment?
3. Should we remove the comment entirely upon DELETE viewpoint?
4. What would be the workflow? as example,

• Delete Viewpoint
• Delete associated comment?
• GET Viewpoints (to refresh client local viewpoints data)
• GET Comments (to refresh client local comments data)

or,

• Delete Viewpoint
• Remove Viewpoint reference from the associated Comment
• PUT Comment
• GET Viewpoints (to refresh client local viewpoints data)
• GET Comments (to refresh client local comments data)

[pasi-paasiala]

@jasollien @ykulbak Can you comment on this?

[Amoki]

At BIMData.io:
On viewpoint delete, we don't delete the attached comments (the viewpoint field is set to null).
On comment delete, we delete the attached viewpoint.
EDIT:
On PUT comment with viewpoint change, we delete the old viewpoint

[ykulbak]

@pasi-paasiala @Noushed Aconex doesn't support deleting viewpoints or comments. I agree this needs to be clarified. My view is that we should keep things simple:

• DELETE Viewpoint - only deletes the viewpoint keeping the comment
• DELETE Comment - only deletes the comment keeping the viewpoint

[ykulbak]

In the OpenCDE Hackathon we decided that a decision matrix should be prepared with options + PROS/CONS for each and detailed implications for implementers should be prepared before making a decision on this issue.

[Noushed]

DELETE viewpoint workflows:

1. Server is the ultimate decider for handling Comments associated with viewpoint to be deleted

Workflow:

• Client checks for Viewpoint removal action (Whether current user is allowed to make such call)
• Client makes DELETE viewpoint call
• Server receives DELETE Viewpoint call, removes the viewpoint and decides whether the comment should be removed or just reference of viewpoint in comment should be removed
• If server sends OK as response, Client will go for fetching comments to update comments in client side

Pros:

• It provides flexibility for servers to decides whether to remove comments completely or just remove the viewpoint reference.
• Client does not need to make extra calls again to update the comments

Cons:

• Extra task for server to handle the Comments upon viewpoint DELETE

2. Client is the ultimate decider for Handling comments associated with Viewpoint

Workflow

• Client will make DELETE viewpoint call
• If response from server is Okay, Client will go for DELETE comment / DELETE viewpoint reference from Comments (Depending on how client wants to behave)

Pros:

• Less deciding work for Server
• Client can decide how to handle Comments associated with viewpoints

Cons:

• If in a project different users use different clients, there will be difference in handling DELETE viewpoint
• It introduces lot more task for Clients as Comments also have actions which will indicate if possible to delete a comment or not

[jasollien]

Hi, I wanna bring this up again.

In BCF it is always possible to delete your own comment.
The only reason you cannot delete a viewpoint, is that it may be backwards referenced by a comment.

I would say it is very random, and that the users should not be "punished" by our technilogical decision.

I also mean is a violation to privacy, that you can't actually delete your own content, just because someone else has commented on it. I think it is important to address that issue seriously. (Note: I don't have any reference to any law that fully backs up this claim)

Therefore, I suggest the following change to be done:

As long as you have access, you can always delete viewpoints, even though comments may be referenced to it. When deleting a viewpoint, that viewpoint should be marked as deleted.

When listing viewpoints in versions <=2.1, those viewpoints should still be returned, but everything (snapshot, camera-positions, components etc...) should be cleared. However, since versions <=2.1 states that either camera, or snapshot should be set. We should expose a "default deleted snapshot" as the snapshot for deleted viewpoints.

Example:

Since version 3.0 is a major versions, we can force those clients to have an active relation to deleted viewpoints.

In v3 we have two options.
1: Expose the viewpoint exactly as in versions <=2.1, but instead of the "default deleted snapshot", we add a "deleted" flag, deleted=true.
Also in the documentation, we say that a viewpoint should at least have one of these: Camera, Snapshot, or be deleted

2: Don't expose the deleted viewpoints at all. Totally ignore it in the /viewpoints endpoint, and if actively fetched (/viewpoints/{guid}), give it an appropriate status code.

I think I lean more towards opt 1.

What do you all think?