Search in non-displayed address books
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 15/100
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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.
- Ngôn ngữ chính
- Kotlin
- Star
- 917
- Fork
- 73
- Merge trung bình
- 2 ngày 2 giờ
- Pull request đã merge (30 ngày)
- 9
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của FossifyOrg/Contacts
-
feature request needs triage
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 72/100
FossifyOrg/Contacts#176 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug needs triage
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 64/100
FossifyOrg/Contacts#618 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
feature request needs triage
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 65/100
FossifyOrg/Contacts#614 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
New field: IBANĐang mởfeature request needs triage
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
FossifyOrg/Contacts#613 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug needs triage
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 52/100
FossifyOrg/Contacts#612 · 5 bình luận · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của FossifyOrg/Contacts
Issue tương tự
-
Dev
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
ankidroid/Anki-Android#22555 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Good first issue: add kotlin-spring-boot stack budget preset (Kotlin + Spring Boot 3 + Gradle)Đang mởenhancement good first issue help wanted
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
-
core: RAC_LLM_OPTIONS_DEFAULT.min_p disagrees with the IDL's annotated defaultCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mởbug core p3
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
RunanywhereAI/runanywhere-sdks#1083 ·
Maintainer thường phản hồi trong vòng 5 ngày
-
enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Java and Kotlin (JVM): parse gradle/wrapper/gradle-wrapper.properties with exact line locationsĐang mởarea: detector eco: java help wanted lane: free-agent roadmap size: S type: parser
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
arminazimi/evergreen#355 ·
Maintainer thường phản hồi trong vòng 1 ngày