Inconsistencies in comment fields, thread views and comment Link URLs

I understand that a comment has exactly as many links as it is present in thread views across all spaces. Each link is associated with the thread view where the comment appears.

However, I see some strange behavior:

SpaceX has DatabaseA with a comment field.
DatabaseA contains EntityA
The comment field in EntityA is initially displayed as a thread of comments.

A comment of EntityA has comment link:[entityID]/comment=[commentID]

When in SpaceY a Thread view ‘ThreadY’ is created based on EntityA, the comment link in that view is[viewID]/comment=[commentID]

First strangeness:

Upon the first creation of a thread view based on EntityA (in any other space), the comment field in EntityA automatically converts from a thread of comments to a button ‘Comments’ which cannot be expanded to a thread view (although the sorting button is still visible, which is strange)
The automatic conversion of a threaded comment field to a button is for a user unexpected and confusing, especially if someone else created that first other thread view.

Second strangeness:

When clicking on the comment button, then thread view ‘ThreadY’ is displayed in a new panel.
Comment link:[commentID]
is now redirected to:[viewID]/comment=[commentID]
Therefore the user, viewing EntityA in SpaceX, suddenly is redirected to a complete other space, SpaceY, where all comments have links based on SpaceY and ThreadY.

It would be more consistent if at the moment the first thread view is created, automatically also a thread view is created in SpaceX in which comments have link[viewID]/comment=[commentID]
(however, even better would be the proposal below)

Third strangeness:

When in SpaceZ a new Thread view ‘ThreadZ’ is created based on EntityA, this has the same affect as when creatiing ThreadY, the comment link is[viewID]/comment=[commentID]
When use clicks on a comment button in EntityA then SpaceY/TreadY opens in a new panel. Why is ThreadY given priority over ThreadZ?


I think all the above can be solved if instead of the confusing converting comment field button, the comment field in EntityA becomes an embedded context thread view just like any other relationship collection field.

1 Like

Threads were/are an experimental feature.
Accordingly, thread view is not a fully fledged data view like others (table, board, etc.)

We’ll take on board the feedback in future work on threads (but no ETA for that)

1 Like