7.7 KiB
- 2021
2021
2021-W33
Timestamp | Tags | Headline | Time | |||
---|---|---|---|---|---|---|
Total time | 1:52 | |||||
2021-W33 | 1:52 | |||||
2021-08-16 Monday | 1:52 | |||||
[2021-08-16 Mon 15:11] | work | Fix Carlos Hidalgo account | 0:20 | |||
<2021-08-16 Mon> | work | create an issue about email… | 1:32 |
2021-08-16 Monday
DONE Fix Carlos Hidalgo account work
CLOCK: [2021-08-16 Mon 15:11]–[2021-08-16 Mon 15:31] => 0:20
[2021-08-16 Mon 15:11]
IN-PROGRESS create an issue about email search case sensitivity work
SCHEDULED: <2021-08-16 Mon>
CLOCK: [2021-08-17 Tue 14:16]–[2021-08-17 Tue 15:44] => 1:28
CLOCK: [2021-08-16 Mon 15:03]–[2021-08-16 Mon 15:07] => 0:04
[2021-08-16 Mon 15:03]
Fix email case sensitivity
> Related https://github.com/threatgrid/response/issues/818
We often need to search by email. The main issue being that, currently our search mechanism does not support case insensitive matches.
We have 4 possible solutions:
- Lower case the user email at creation. We need to also update the user emails in our DB. The safest route to achieve this will be via the iroh-migration service.
- Keep the email case sensitive and add a new case insensitive field
lc-user-email
for example. But same as for case 1, we need to perform a DB migration to add this new field to all existing user in DB.
- Add support for case insensitive search in tk-store, perhaps with a new
tk-store service, or improving current
CRUDStoreService.
- Add a specific service just for search user emails that could take care of this specific case by using a Postgres specific query. This could also be the occasion to provide a tk-store hole in the abstraction service.
The simplest is probably option 1. Option 2 would be slightly more complex and we would not lose any detail. Option 3 seems the most generic one, and we could totally imagine we would appreciate a case insensitive search support. Option 4 looks like a specific case of 3.
My preference then goes to option 3, but we need to understand if this is
not too difficult to achieve, what would be the API? The most natural one
would probably add an option along filter-map
like case-insensitive-fields
.
One issue would be to write the support for case insensitive match for atom
and redis
.
TODO Interview Steven Collins
CLOCK: [2021-08-16 Mon 15:49]–[2021-08-16 Mon 19:04] => 3:15
2021-08-17 Tuesday
TODO Add scope to TG clients work
DEADLINE: <2021-08-18 Wed>
CLOCK: [2021-08-17 Tue 17:54]
[2021-08-17 Tue 17:54]
In tenzin config:
- INT: 34d94c8c-2041-4708-8172-ebe2df295ca7-2
- TEST: f993f6a0-8075-43e0-a9e5-dae9c3980513
- NAM: 7b8d9fef-bd93-4ef3-88af-ae4174ee02e5
- EU: a1662193-9155-44fd-aa1f-43afd42c889c
IN-PROGRESS Write an issue about 1-click module setup work
SCHEDULED: <2021-08-17 Tue>
CLOCK: [2021-08-17 Tue 15:51]–[2021-08-17 Tue 17:54] => 2:03
[2021-08-17 Tue 15:51]