topics: Convert topic links to permalinks. #30114

roanster007 · 2024-05-16T12:46:22Z

Commit 1: adds a new narrow operator -- "with" which expects a string operand of message_id, and returns all the messages in the same channel and topic of the operand, with the first unread message of the topic as anchor.

Commit 2: Converts #-mention of topics to permalinks.

Commit 3: Converts left sidebar topic links and Copy link to topic to permalinks.

Fixes: #21505

Self-review checklist

Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

Explains differences from previous plans (e.g., issue description).
Highlights technical choices and bugs encountered.
Calls out remaining decisions and concerns.
Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

Each commit is a coherent idea.
Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

Visual appearance of the changes.
Responsiveness and internationalization.
Strings and tooltips.
End-to-end functionality of buttons, interactions and flows.
Corner cases, error conditions, and easily imagined bugs.

gnprice · 2024-05-16T19:46:02Z

Chat threads in #design and #api design, for cross-reference:
https://chat.zulip.org/#narrow/stream/101-design/topic/redirects.20from.20near.20links/near/1774401
https://chat.zulip.org/#narrow/stream/378-api-design/topic/topic.20permalinks/near/1801198

roanster007 · 2024-05-20T14:51:24Z

Updated narrow with operator as per the api design thread --

If message is found in local cache, use it to return the message list.
If message not found in local cache, don't fetch the message_id attached to with operator recursively, but send the entire narrow to backend and to correct the operator and fetch the message list.

zerver/openapi/zulip.yaml

zerver/lib/narrow.py

zerver/lib/message.py

timabbott · 2024-05-20T23:05:29Z

zerver/lib/narrow.py

+
+            narrow.remove(with_term)
+
+    return narrow


I think we will want this function to also return at least a boolean for whether the narrow was in fact modified from its original state; I think there's a good chance we'll want to have the API response do something to reflect whether that in fact occurred.

we can decide it in the client side whether the narrow has been updated or not. I updated it to use the client side implementation.

zerver/lib/narrow.py

api_docs/construct-narrow.md

web/src/filter.ts

timabbott · 2024-05-20T23:12:13Z

web/src/narrow.js

-        id_info.final_select_id = min_defined(id_info.target_id, unread_info.msg_id);
+        id_info.final_select_id = filter.has_operator("with")
+            ? unread_info.msg_id
+            : min_defined(id_info.target_id, unread_info.msg_id);


Why is this the right special case?

well, in case of this with operator, we populate the target_id with the operand. The final_select_id in our case should always be the first unread if found locally (else undefined, so that we can fetch it from server). It is however possible that out target_id (basically the with operand) might be < first unread msg_id theroetically

web/src/narrow.js

timabbott · 2024-05-20T23:15:00Z

web/src/narrow.js

@@ -94,6 +94,56 @@ export function save_narrow(terms, trigger) {
    changehash(new_hash, trigger);
 }

+function change_view_for_narrow_containing_with_operator(message_data, opts) {


I'm not sure I see anywhere where this logic would avoid doing a bunch of work in the very common case that the target message has never moved. Possibly the message_fetch API response suggested elsewhere would be helpful to you here for doing this check well.

I added the logic so that it would avoid the work in case it is in the same narrow.

web/src/narrow.js

timabbott · 2024-05-20T23:17:40Z

web/tests/filter.test.js

+        {operator: "with", operand: 17},
+    ];
+    filter = new Filter(terms);
+    assert.ok(filter.can_bucket_by("channel", "with"));


Is it correct to say we can bucket by those operators? We don't actually know which messages are in the current conversation... We might need to be careful here.

Can you comment on how you addressed this feedback detail? Generally it's best practice for every thread to include explanation of how the feedback was resolved.

So in the current version of PR, I only use can_bucket_by("channel", "topic", "with") in the PR.

Since the with operator is not available in the search suggestion, and is only through either topic-mentions or left_sidebar, I guess it is certain that operations involving with only contain the above operands.

web/tests/narrow_unread.test.js

This commit extracts the method to create and update message lists in the narrow. This is particularly useful in cases when we need to update the narrow and view with our own message lists. This is a preparatory commit to zulip#30114, since it involves creating a new message list from the messages fetched, which may be of a different narrow from that of the initial filter, and updating the view and narrow with it.

This commit extracts the method to create and update message lists in the narrow. This is particularly useful in cases when we need to update the narrow and view with our own message lists. This is a preparatory commit to #30114, since it involves creating a new message list from the messages fetched, which may be of a different narrow from that of the initial filter, and updating the view and narrow with it.

roanster007 · 2024-05-23T13:47:41Z

web/src/narrow.js

+    // raw_terms with both `dm` and with operators are redundant, since dms
+    // don't have topics. Hence, we remove the `with` operator.
+    if (raw_terms.some((term) => term.operator === "dm")) {
+        raw_terms = raw_terms.filter((term) => term.operator !== "with");
+    }


I assume private messages containing with operators would be redundant since they can't be moved?

I think that's correct, it should be a noop on DMs for now.

But we may change that behavior. I'll link to #20501 so that there's a reference on that issue of this detail. I'm not convinced much more effort is required.

roanster007 · 2024-05-23T19:24:11Z

addressed the above reviews.

roanster007 · 2024-06-01T13:58:14Z

Updates:

refined the update_narrow_terms_containing_with_operator method (which corrects the narrow operator when with is present) as per the review
Added commit to use the topic permalinks in left-sidebar topic links, and Copy topic link of topic popover
Addressed the reviews of construct-narrow.

api_docs/construct-narrow.md

This commit adds a new narrow operator -- "with" which expects a string operand of message_id, and returns all the messages in the same channel and topic of the operand, with the first unread message of the topic as anchor. This is done as an effort to provide permalinks for topics in zulip#21505.

This commit converts the links generated by the markdown of the "#-mention" of topics to permalinks -- the links containing the "with" narrow operator, the operand being the last message of the channel and topic of the mention. Partly Fixes zulip#21505

This commit updates the topic links obtained from clicking the topics and those obtained from "Copy link to topic" to use the new topic permalinks. Fixes zulip#21505

zulipbot added the size: XL label May 16, 2024

roanster007 force-pushed the iss-21505 branch from 6a99ef3 to 24a5aad Compare May 16, 2024 12:52

roanster007 force-pushed the iss-21505 branch from 24a5aad to 0f5a750 Compare May 20, 2024 14:48

roanster007 force-pushed the iss-21505 branch 2 times, most recently from a6b737a to df4829a Compare May 20, 2024 17:00