Search in non-displayed address books
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 15/100
Direzione di ricerca
The payload names no files, so start by finding where the address book filter list on the Contacts and Favorites tabs is built and where search is run. Read the linked #233 and #483 first, since the author says this overlaps with them. The design is still open: it needs a decision on the three-way selector and on whether results merge or show an "other contacts" heading, so ask a maintainer before writing code.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Checklist
- I made sure that there are no existing issues - open or closed - to which I could contribute my information.
- I made sure that there are no existing discussions - open or closed - to which I could contribute my information.
- I have read the FAQs inside the app (Menu -> About -> FAQs) and my problem isn't listed.
- I have taken the time to fill in all the required details. I understand that the request will be dismissed otherwise.
- This issue contains only one feature request.
- I have read and understood the contribution guidelines.
Feature description
I would like the address book filter list affecting the Contacts and Favorites tabs not to have checkboxes (boolean) but rather three-way selectors. The three options would indicate "hide" (empty or X icon etc, "search only" (magnifying glass icon), "show in list" (eye icon).
The first and last options would treat address books as "no" and "yes" currently do.
Setting an address book to "search only" would not cause the contacts in that address book to be shown in the list of contacts, but a search would match contacts in those address books.
As part of this, an application setting could determine whether the results list is a merge of all the results, or the top results are from "show in list" groups (i.e. the current result population) and then (as needed) a heading "other contacts" followed by the contacts found in the "search only" groups.
Why do you want this feature?
I have address books for different groups of contacts. When I browse, I want to scan only my most significant contacts, a much smaller group (and have set up the app accordingly), but when searching I'm often looking for someone in the wider set. Right now I don't find the latter contacts at all. As a result, I end up using a second contacts app (the default Google one) for searches across all address books. I'd rather manage my contacts in the one app / It will provide a solution for those who only want one contacts app installed.
The implementation I have suggested is (I believe) preferable to an application setting of "search in all address books" because that's not necessarily what the user will want; the three-way selectors allow granular configuration. In addition it will put that search-only option right in front of the user.
Additional information
I'm concerned that this is a little bit similar to #233 and #483, but I reckon that it's different enough to submit as a separate feature request.
- Lingua principale
- Kotlin
- Stelle
- 917
- Fork
- 73
- Merge medio
- 2g 2h
- PR unite (30g)
- 9
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di FossifyOrg/Contacts
-
feature request needs triage
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 72/100
FossifyOrg/Contacts#176 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
bug needs triage
Difficoltà 3/5 1-2 giorni Idoneità per principianti 64/100
FossifyOrg/Contacts#618 ·
I maintainer di solito rispondono entro 1 giorno
-
feature request needs triage
Difficoltà 3/5 1-2 giorni Idoneità per principianti 65/100
FossifyOrg/Contacts#614 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
New field: IBANApertafeature request needs triage
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
FossifyOrg/Contacts#613 ·
I maintainer di solito rispondono entro 1 giorno
-
bug needs triage
Difficoltà 4/5 3-5 giorni Idoneità per principianti 52/100
FossifyOrg/Contacts#612 · 5 commenti · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di FossifyOrg/Contacts
Issue simili
-
Dev
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
ankidroid/Anki-Android#22555 ·
I maintainer di solito rispondono entro 1 giorno
-
Good first issue: add kotlin-spring-boot stack budget preset (Kotlin + Spring Boot 3 + Gradle)Apertaenhancement good first issue help wanted
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
-
core: RAC_LLM_OPTIONS_DEFAULT.min_p disagrees with the IDL's annotated defaultForse già presa Una pull request collegata a questa issue è aperta o già unita. Apertabug core p3
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
RunanywhereAI/runanywhere-sdks#1083 ·
I maintainer di solito rispondono entro 5 giorni
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
I maintainer di solito rispondono entro 1 giorno
-
Java and Kotlin (JVM): parse gradle/wrapper/gradle-wrapper.properties with exact line locationsApertaarea: detector eco: java help wanted lane: free-agent roadmap size: S type: parser
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
arminazimi/evergreen#355 ·
I maintainer di solito rispondono entro 1 giorno