feat: improve user assignments via quick add magic #3348

Merged
konrad merged 18 commits from feature/better-user-search-assignees into main 2023-06-05 15:03:16 +00:00
Showing only changes of commit 218a19d907 - Show all commits

View File

@ -30,6 +30,10 @@ import {useKanbanStore} from '@/stores/kanban'
import {useBaseStore} from '@/stores/base'
import ProjectUserService from '@/services/projectUsers'
interface MatchedAssignees extends IUser {
konrad marked this conversation as resolved Outdated

This should be singular, like IUser

This should be singular, like `IUser`

Done

Done
match: string,
}
// IDEA: maybe use a small fuzzy search here to prevent errors
dpschen marked this conversation as resolved
Review
For a simple implementation copy over: https://github.com/hiddentao/fast-levenshtein/blob/3.0.0/levenshtein.js
Review

Why copy it instead of pulling it in as a dependency?

We don't do any fancy matching in the api (other than lowercase contains), which means the frontend can't find things with fuzzy matching which the api did not return in the first place. I feel like we should fuzzy matching in the api first and then add it in the frontend as well.

Why copy it instead of pulling it in as a dependency? We don't do any fancy matching in the api (other than lowercase contains), which means the frontend can't find things with fuzzy matching which the api did not return in the first place. I feel like we should fuzzy matching in the api first and then add it in the frontend as well.
Review

The module is a slim wrapper around fastest-levenshtein with some sensible defaults and using Intl.Collator. The wrapper is a bit dated. So I would only copy the function as a helper and import fastest-levenshtein directly. Fuzzy matching in the api makes sense.

Doing it in the frontend as well for the locally available data still makes sense, because fuzzy finding increases the chance that the wanted result is further at the top in the list of found results.

This is a really cheap method with a big impact. For the backend I would probably try to use something better directly.

The module is a slim wrapper around [fastest-levenshtein](https://github.com/ka-weihe/fastest-levenshtein) with some sensible defaults and using [Intl.Collator](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Collator). The wrapper is a bit dated. So I would only copy the function as a helper and import fastest-levenshtein directly. Fuzzy matching in the api makes sense. Doing it in the frontend as well for the locally available data still makes sense, because fuzzy finding increases the chance that the wanted result is further at the top in the list of found results. This is a really cheap method with a big impact. For the backend I would probably try to use something better directly.
Review

But if the frontend and api both do fuzzy matching, what's the advantage of doing it in the frontend as well? Wouldn't that give use the same results? (right now neither does, but it should be done in the api anyway)

But if the frontend and api both do fuzzy matching, what's the advantage of doing it in the frontend as well? Wouldn't that give use the same results? (right now neither does, but it should be done in the api anyway)
Review

We have a few points in the code where we used strict matching for searching in local (aka downloaded to frontend) data. I thought this was one of those places. Since adding levenshtein seems simple I thought we would have a quick-win here. If we are offline first this also enables usage when offline without server request. To get up-to-date data an api-request is obviously unavoidable. So I'm unsure what our general strategy here is, I guess?

We have a few points in the code where we used strict matching for searching in local (aka downloaded to frontend) data. I thought this was one of those places. Since adding levenshtein seems simple I thought we would have a quick-win here. If we are offline first this also enables usage when offline without server request. To get up-to-date data an api-request is obviously unavoidable. So I'm unsure what our general strategy here is, I guess?
Review

Sure, we could add it but I'm not sure how useful that would be in the current state. The offline argument sticks though… but then we could do that when we have offline storage. Better not complicate things more than we must right now to solve this.

Sure, we could add it but I'm not sure how useful that would be in the current state. The offline argument sticks though… but then we could do that when we have offline storage. Better not complicate things more than we must right now to solve this.
function findPropertyByValue(object, key, value) {
return Object.values(object).find(
@ -37,11 +41,23 @@ function findPropertyByValue(object, key, value) {
)
}
function findPropertyByValueFuzzy(object, key, value) {
return Object.values(object).find(
(l) => l[key]?.toLowerCase().includes(value.toLowerCase()),
)
}
// Check if the user exists in the search results
function validateUser(
users: IUser[],
query: IUser['username'] | IUser['name'] | IUser['email'],
) {
if (users.length === 1) {
return findPropertyByValueFuzzy(users, 'username', query) ||
findPropertyByValueFuzzy(users, 'name', query) ||
findPropertyByValueFuzzy(users, 'email', query)
}
return findPropertyByValue(users, 'username', query) ||
konrad marked this conversation as resolved Outdated

Fuzzy should be an option of findPropertyByValue.
Picky: use bracket to group return value.

return (
	findPropertyByValue(users, 'username', query) ||
	findPropertyByValue(users, 'name', query) ||
	findPropertyByValue(users, 'email', query)
)
Fuzzy should be an option of `findPropertyByValue`. Picky: use bracket to group return value. ```ts return ( findPropertyByValue(users, 'username', query) || findPropertyByValue(users, 'name', query) || findPropertyByValue(users, 'email', query) )

Done

Done
findPropertyByValue(users, 'name', query) ||
findPropertyByValue(users, 'email', query)
@ -63,14 +79,18 @@ async function addLabelToTask(task: ITask, label: ILabel) {
return response
}
async function findAssignees(parsedTaskAssignees: string[], projectId: number): Promise<IUser[]> {
async function findAssignees(parsedTaskAssignees: string[], projectId: number): Promise<MatchedAssignees[]> {
if (parsedTaskAssignees.length <= 0) {
return []
}
const userService = new ProjectUserService()
const assignees = parsedTaskAssignees.map(async a => {
const users = await userService.getAll({projectId}, {s: a})
const users = (await userService.getAll({projectId}, {s: a}))

The bracket around seems to be unnecessary.

What I meant: Seems better to use await with then here

~~The bracket around seems to be unnecessary.~~ What I meant: Seems better to use `await` with `then` here

Don't you mean then without await?

Don't you mean `then` without `await`?

No. You still need to await the resulting promise comining out of the then

No. You still need to await the resulting promise comining out of the then

Then what's the advantage of the extra then over the current solution?

Then what's the advantage of the extra `then` over the current solution?
.map(u => ({
...u,
match: a,
}))
return validateUser(users, a)
})
@ -388,17 +408,15 @@ export const useTaskStore = defineStore('task', () => {
cancel()
throw new Error('NO_PROJECT')
}
const assignees = await findAssignees(parsedTask.assignees, foundProjectId)

assignees is used to create a task via new TaskModel. findAssignees now returns an array of MatchedAssignee(s) instead of IUser[] which is what new TaskModel expects as type for the assignees property

`assignees` is used to create a task via `new TaskModel`. `findAssignees` now returns an array of `MatchedAssignee`(`s`) instead of `IUser[]` which is what `new TaskModel` expects as type for the `assignees` property

That should not be a problem, because MatchedAssignee implements IUser and thus can be used as such. If it can quack like a duck, it can be used as a duck, no matter what else it is capable of doing.
The match property of MatchedAssignee will be ignored by the model (from the type perspective, in reality it will be sent to the api which will then ignore it).

That should not be a problem, because `MatchedAssignee` implements `IUser` and thus can be used as such. If it can quack like a duck, it can be used as a duck, no matter what else it is capable of doing. The `match` property of `MatchedAssignee` will be ignored by the model (from the type perspective, in reality it will be sent to the api which will then ignore it).
// Only clean up those assignees from the task title which actually exist
let cleanedTitle = parsedTask.text
if (assignees.length > 0) {
const assigneePrefix = PREFIXES[quickAddMagicMode]?.assignee
if (assigneePrefix) {
cleanedTitle = cleanupItemText(cleanedTitle, assignees.map(a => a.email), assigneePrefix)
cleanedTitle = cleanupItemText(cleanedTitle, assignees.map(a => a.username), assigneePrefix)
cleanedTitle = cleanupItemText(cleanedTitle, assignees.map(a => a.name), assigneePrefix)
cleanedTitle = cleanupItemText(cleanedTitle, assignees.map(a => a.match), assigneePrefix)
}
}