Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[front] - chore(InputBar):support slack URL pasting #11492

Open
wants to merge 16 commits into
base: main
Choose a base branch
from

Conversation

JulesBelveze
Copy link
Contributor

@JulesBelveze JulesBelveze commented Mar 20, 2025

Description

This PR adds support for Slack URLs in the nodeIdFromUrl utility function. It now handles three types of Slack URLs:

  1. Channel URLs: https://app.slack.com/client/TEAM_ID/CHANNEL_IDslack-channel-CHANNEL_ID
  2. Thread URLs: https://team.slack.com/archives/CHANNEL/TIMESTAMP?thread_ts=THREAD_TSslack-CHANNEL-thread-THREAD_TS
  3. Message URLs: https://team.slack.com/archives/CHANNEL/pTIMESTAMPslack-CHANNEL-messages-YYYY-M-D-YYYY-M-D (weekly range)

Since those mime types were filtered out during search we introduce a "useCase" parameter on the search endpoint, to filter out relevant mime types depending on the use case at hand.

Risk

Low, behind FF

Deploy Plan

Deploy front

 - Added a list of MIME types for nodes that cannot be pasted

[front/lib/swr] - feature: support use case distinction in search parameters

 - Enhanced search function to differentiate between paste and search node use cases

[front/pages/api] - refactor: filter search results based on use case

 - Implemented use case-specific exclusion of node MIME types in search results
…action

 - Implement URL matching and information extraction for Slack archive links
 - Support both thread-specific links and message links within a specific week range
… bar container

 - Include a new 'useCase' prop to enhance the input bar's functionality

[front/lib] - refactor: streamline slack URL node ID extraction

 - Refactor URL node ID extraction for Slack by structuring it in individual methods
 - Utilize a common utility method 'getWeeklyDateRange' to calculate weekly date ranges for messages
- Removed `client_side_new_id` as it was relying on UUIDs, which are not needed anymore
- Deleted `utcDateFrom` function since it's no longer being used in the codebase
- Eliminated the `trimText` function to streamline the utilities available
 - Implement Slack URL matching and node ID extraction for different Slack URL patterns
 - Extend utils with `getWeeklyDateRange` function to assist in generating Slack message node IDs

[extension/ui] - refactor: include `useCase` in spaces search hook and input bar container

 - Pass "pasteUrl" as `useCase` to spaces search hook when used within `InputBarContainer`
 - Ensure the new use case parameter aligns with different usage scenarios for the search hook
 - Added a new union type for `ContentNodeSearchUseCase` to handle different search scenarios
 - Extended `BaseSearchBodySchema` with a `useCase` field to utilize the new search use cases in requests
Copy link

github-actions bot commented Mar 20, 2025

Fails
🚫

Files in **/api/v1/ have been modified. Please add the documentation-ack label to acknowlegde that if anything changes
in a public endpoint, you need to edit the JSDoc comment
above the handler definition and/or the swagger_schemas.ts file and regenerate the documentation using npm run docs

🚫

Files in **/sdks/js/ have been modified. Changing the types defined in the SDK could break existing client.
Additions (new types, new values) are generally fine but removals are NOT OK : it would break the contract of the Public API.
Please add the sdk-ack label to acknowledge that your are not breaking the existing Public API contract.

Generated by 🚫 dangerJS against f219b4c

 - Removed the 'undefined' type from the useCase union in BaseSearchBody, enforcing explicit useCase specification

[sdks] - fix: remove undefined type from ContentNodeSearchUseCase

 - Corrected the ContentNodeSearchUseCase by removing the option for it to be undefined, ensuring consistency with the API changes
 - Extended search API to support a 'useCase' parameter with enum options
 - The new parameter helps differentiate search contexts, such as 'pasteUrl' or 'searchNode'
Copy link
Contributor

@philipperolet philipperolet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👋 We might have misunderstood each other here (no biggie)
The point when I added slack threads back into the mix was "because it was extremely simple" (I thought I had told you that, sorry if I didnt). The converse being that if it turns out not to be simple, we leave it out of the mix

The goal as per the card was only to support threads; wouldn't that have been just adding a matcher and extractor in Provider?
If yes, let's go for that. If not, let's discuss if we move forward, not sure it's worth the added complexity

Happy to discuss IRL :)

 - Changed providers object keys to match ConnectorProvider type definition

[front/lib] - refactor: align connector provider keys with shared definitions

 - Updated provider keys in the providers object to ensure consistency with shared connector naming convention
Copy link
Contributor

@philipperolet philipperolet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks great, as discussed aro we can move forward with this PR. left a few you comments but mosty I would avoid using "useCase" and rather expose mimetypes, I think it'd be more readable avoiding creating a new abstraction

extractor: (url: URL): string | null => {
// Try each type of extraction in order
return (
extractChannelNodeId(url) ||
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are we sure we'll never exit with a channel while there was actually a thread?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or like this is a bit tricky to read logic fast, but if we have to keep it IMO start with the most specific (thread) and end with the most general (channel)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Channel have "client" in the URL, while thread and messages have "archives", so we should be safe here 👌🏼
Will reorder checks


// Extract a thread node ID from a Slack archives URL
function extractThreadNodeId(url: URL): string | null {
const pathParts = url.pathname.split("/");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: threads always have archive?

Copy link
Contributor Author

@JulesBelveze JulesBelveze Mar 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like it yes and messages too 👍🏼

return { startDate, endDate };
}

function getWeekEnd(startDate: Date): Date {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: a bit ricky here to have weekstart work with any date but wekend needs the weekstart while they have the same naming patttern.
would either have only one fn returning both or have both woek with any date

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair

@@ -9,26 +8,13 @@ export function classNames(...classes: (string | null | boolean)[]) {
return classes.filter(Boolean).join(" ");
}

export function client_side_new_id() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is that related?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a clean up 🧹 (saw there was a few unused functions)

 - Deleted the `useCase: "pasteUrl"` property from search components and API
 - Removed `NON_PASTABLE_NODES_MIME_TYPES` as it's no longer needed due to the removal of the pasteUrl use case
 - Updated SWR hooks and API handlers to exclude the useCase parameter from their logic

[sdks] - refactor: eliminate ContentNodeSearchUseCase type

 - Removed the `ContentNodeSearchUseCase` enum as the pasteUrl use case is no longer supported
… and input bar

 - Eliminated the 'useCase' property handling from useSpacesSearch hook
 - Removed 'useCase' from input props to simplify pasteUrl functionality
 - Cleaned up related effect and params in InputBarContainer to align with hook changes
 - Consolidate week boundary logic into a single `getWeekBoundaries` function
 - Remove separate `getWeekStart` and `getWeekEnd` functions for simplification

[connectors] - refactor: update usage of week boundary utilities

 - Replace `getWeeklyDateRange` with `getWeekBoundaries` to adhere to updated utils
 - Reorder extraction methods for consistency and potential performance benefits
 - Recognize and handle Slack thread and message URLs with "/archives/" in the path
 - Identify Slack channel URLs that contain "/client/" in the pathname
Copy link
Contributor

@philipperolet philipperolet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants