What:
Growth wants to use ApiDiscussionToolsEdit to
post questions on behalf of new users (to make use
of the auto-subscribing logic DiscussionTools has).
This seems like a good moment to make the API
non-internal.
What:
* Add support for 'tags' parameter
(this doesn't actually work w/o the depends-on)
* Add autosubscribe parameter to give more control
to callers over whether autosubscription is used.
* Remove isInternal()
Bug: T343339
Bug: T333632
Depends-On: I0ac60ca8473fe28461b2da60f9911baac4994388
Change-Id: I39727de40557d2494f4d60bf224490caaedfdee1
Our edit API now recognizes topic subjects in the message body,
generates edit summaries from them, and optionally returns an error
if no subject is provided.
Bug: T334163
Bug: T338390
Change-Id: Iac3778a4a88a4def234be9d10b80d9796d35bceb
Special:DiscussionToolsDebug falsely promised that the API delivers
the same information, but in fact the API included the signatures in
each comment's HTML unconditionally. Allow excluding them.
Change-Id: Ie1e38d28bed0b6d5713d9051b84cc08a23da94c2
Exposed as DiscussionToolsPageInfo prop threaditemshtml. It returns a
version of the output of CommentParser, lightly adjusted to provide a
nested comment structure rather than a pure flat list.
Bug: T285971
Change-Id: I2f8503d4ed740a04fb2f1e3a37ae4db649b3faba
We were rendering the preview in a completely different way from how
we would add the real reply, and the results would be different
sometimes, particularly for multi-line comments with messed-up markup.
Render it server-side instead, in a very similar way to real replies
(generating a DOM list node and transforming it through Parsoid),
although without the whole context of the page to improve performance.
We can remove a lot of client-side code that was used solely for this.
This will allow the preview to accurately display the signatures when
we change how they are added (T278442), without us having to implement
those changes again from scratch for the preview.
Change-Id: I53341f4d4075c25b67ec3b3032bff9b8a880dcd3
For two given revisions, this API tells us which comments have
been added and which have been removed.
Can be used to highlight new comments, or check if the page
has been updated since we first loaded it.
Bug: T281624
Bug: T300504
Change-Id: Ia4d95ffe3b7cf2317cd8e7c0f034e09f64777ef3
Per Manuel Arostegui in T263817#7033384. The limit is 5000.
(I picked it arbitrarily, there's no real rationale for it.)
Also log a warning when any user reaches half of the limit,
so that we might make a decision about changing this mechanism
before it starts affecting users. Maybe at that time we'll
have data to show that it's safe to remove the limit.
Bug: T263817
Change-Id: I18a8ee0ad7383759229c5721d5253fb591457d4d
The existing comment IDs can't be used to find the same comment on
a different revision or page (when it's transcluded), because they
depend on the comment's parent and its position on the page.
Comment names depend only on the author and timestamp. The trade-off
is that they can't distinguish comments posted within the same minute,
or in the same edit, so we will still need the IDs sometimes.
Prefer using comment names when replying, if they're not ambiguous.
This fixes T273413 and T275821.
Heading names depend on the author and timestamp of the oldest comment.
This way we don't have to detect changes to the heading text, but we
can't distinguish headings without any comments.
Bug: T274685
Bug: T273413
Bug: T275821
Change-Id: Id85c50ba38d1e532cec106708c077b908a3fcd49
The text of this message looks like a description for a 'summary'
parameter for the API (which doesn't exist, and if it did, we'd reuse
the message from core anyway). It's supposed to contain an overall
summary/description of the whole module.
Change-Id: I110d0ac6cd6fa9c2dc171615cbf1cd9629452d5a
