feat: improve user assignments via quick add magic #3348
|
@ -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
|
||||
match: string,
|
||||
}
|
||||
|
||||
// IDEA: maybe use a small fuzzy search here to prevent errors
|
||||
dpschen marked this conversation as resolved
dpschen
commented
For a simple implementation copy over: https://github.com/hiddentao/fast-levenshtein/blob/3.0.0/levenshtein.js For a simple implementation copy over: https://github.com/hiddentao/fast-levenshtein/blob/3.0.0/levenshtein.js
konrad
commented
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.
dpschen
commented
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.
konrad
commented
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)
dpschen
commented
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?
konrad
commented
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
dpschen
commented
Fuzzy should be an option of
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)
)
konrad
commented
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}))
|
||||
dpschen
commented
What I meant: Seems better to use ~~The bracket around seems to be unnecessary.~~
What I meant: Seems better to use `await` with `then` here
konrad
commented
Don't you mean Don't you mean `then` without `await`?
dpschen
commented
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
konrad
commented
Then what's the advantage of the extra 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)
|
||||
dpschen
commented
`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
konrad
commented
That should not be a problem, because 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)
|
||||
}
|
||||
}
|
||||
|
||||
|
|
This should be singular, like
IUser
Done