Private Issues: Research questions about public/private comment split #602

New issue

Closed

opened 2026-06-01 12:05:43 +00:00 by nphilipp · 3 comments

nphilipp commented

2026-06-01 12:05:43 +00:00

Member

Summary

Research ways to point to comments within an issue/PR page when their IDs alone don’t guarantee uniqueness.

Background

The ID field of a Comment is used in constructing anchors pointing directly to the respective comment. If there are both public and private comments in their own tables, their ID fields alone aren’t suitable to uniquely identify them.

# Summary Research ways to point to comments within an issue/PR page when their IDs alone don’t guarantee uniqueness. # Background The `ID` field of a `Comment` is used in constructing anchors pointing directly to the respective comment. If there are both public and private comments in their own tables, their ID fields alone aren’t suitable to uniquely identify them.

nphilipp added this to the Sprint 22 project

2026-06-01 12:24:20 +00:00

nphilipp self-assigned this

2026-06-01 12:24:38 +00:00

nphilipp added a new dependency

2026-06-01 12:24:55 +00:00

#594 Private Issues: “Privatize” Comments

nphilipp commented

2026-06-01 14:41:20 +00:00

Author

Member

Currently, Comment generates hash tags for comments in the form of issuecomment-{ID}, see here in models/issues/comment.go):

// CommentHashTag returns unique hash tag for comment id.
func CommentHashTag(id int64) string {
	return fmt.Sprintf("issuecomment-%d", id)
}

// HashTag returns unique hash tag for comment.
func (c *Comment) HashTag() string {
	return CommentHashTag(c.ID)
}

In order for these IDs to be stable – so that links they are referenced by don’t break – the portion of the hash-tag before the ID must be different for comments originating as private comments, e.g. privateissuecomment-{ID}, and whatever the hash tag is must survive conversion from public to private or vice versa (see #603). This doesn’t have to be implemented fully yet from the get-go, but the distinction must be made so that hash tags of either type of comment are guaranteed to be unique should they end up being mixed up when conversion between public and private issues (and their comments) becomes a thing.

Currently, `Comment` generates hash tags for comments in the form of `issuecomment-{ID}`, see here in `models/issues/comment.go`): ```` // CommentHashTag returns unique hash tag for comment id. func CommentHashTag(id int64) string { return fmt.Sprintf("issuecomment-%d", id) } // HashTag returns unique hash tag for comment. func (c *Comment) HashTag() string { return CommentHashTag(c.ID) } ```` In order for these IDs to be stable – so that links they are referenced by don’t break – the portion of the hash-tag before the ID must be different for comments originating as private comments, e.g. `privateissuecomment-{ID}`, and whatever the hash tag is must survive conversion from public to private or vice versa (see #603). This doesn’t have to be implemented fully yet from the get-go, but the distinction must be made so that hash tags of either type of comment are guaranteed to be unique should they end up being mixed up when conversion between public and private issues (and their comments) becomes a thing.

nphilipp added a new dependency

2026-06-01 14:53:53 +00:00

#113 Private Issues

nphilipp referenced this issue

2026-06-01 14:54:41 +00:00

Private Issues #113

nphilipp commented

2026-06-03 10:27:28 +00:00

Author

Member

Turns out that there are more methods affected by public/private comment IDs not being unique:

APIURL() resolves to …/issues/comments/{ID} beneath the repo
CommentHashTag() ⇐ HashTag(), as mentioned
EventTag() resolves to event-{ID}, used as element ID inside a page

Other methods exist which delegate to HashTag() some way or other:

Link() ⇒ hashLink() ⇒ HashTag()
CodeCommentLink() ⇒ HashTag()
CodeCommentLink() ⇒ Link() ⇒ …
RefCommentLink() (⇒ RefIssueLink()) ⇒ Link() ⇒ …
RefIssueLink() ⇒ Link() ⇒ …

Turns out that there are more methods affected by public/private comment IDs not being unique: - `APIURL()` resolves to `…/issues/comments/{ID}` beneath the repo - `CommentHashTag()` ⇐ `HashTag()`, as mentioned - `EventTag()` resolves to `event-{ID}`, used as element ID inside a page Other methods exist which delegate to `HashTag()` some way or other: - `Link()` ⇒ `hashLink()` ⇒ `HashTag()` - `CodeCommentLink()` ⇒ `HashTag()` - `CodeCommentLink()` ⇒ `Link()` ⇒ … - `RefCommentLink()` (⇒ `RefIssueLink()`) ⇒ `Link()` ⇒ … - `RefIssueLink()` ⇒ `Link()` ⇒ …

nphilipp commented

2026-06-03 13:53:15 +00:00

Author

Member

As a result:

MUST: APIURL() and CommentHashTag() ⇒ HashTag() must be distinctive between public and private comments, such as prefixing the respective private comment ID contained with e.g. a "P" character for distinction.
MUST if stable links are desired and public/private can be converted into the other: save the (prefixed) "original" ID on conversion, and use it if present.

As a result: - **MUST**: `APIURL()` and `CommentHashTag()` ⇒ `HashTag()` must be distinctive between public and private comments, such as prefixing the respective private comment ID contained with e.g. a "P" character for distinction. - **MUST** if stable links are desired and public/private can be converted into the other: save the (prefixed) "original" ID on conversion, and use it if present.

nphilipp closed this issue

2026-06-03 13:53:15 +00:00