trent_larson/crowd-funder-for-time-pwa
4
1
Fork 2
Code Issues Pull Requests 22 Releases 5 Wiki Activity

feat: implement member visibility dialog with checkbox selection and refresh #208

Merged
jose merged 9 commits from meeting-members-set-visibility into master 2025-10-21 08:52:15 +00:00
Conversation 4 Commits 9 Files Changed 6 +651 -115
jose commented 2025-10-14 13:23:09 +00:00
Owner
Copy Link
  • Add "Set Visibility" dialog for meeting members who need visibility settings
  • Filter members to show only those not in contacts or without seesMe set
  • Implement checkbox selection with "Select All" functionality
  • Add reactive checkbox behavior with proper state management
  • Default all checkboxes to checked when dialog opens
  • Implement "Set Visibility" action to add contacts and set seesMe property
  • Add success notifications with count of affected members
  • Disable "Set Visibility" button when no members are selected
  • Use notification callbacks for data refresh
  • Hide "Set Visibility" buttons when no members need visibility settings
  • Add proper dialog state management and cleanup
  • Ensure dialog closes before triggering data refresh to prevent stale states

The implementation provides a smooth user experience for managing member visibility settings with proper state synchronization between components.

- Add "Set Visibility" dialog for meeting members who need visibility settings - Filter members to show only those not in contacts or without seesMe set - Implement checkbox selection with "Select All" functionality - Add reactive checkbox behavior with proper state management - Default all checkboxes to checked when dialog opens - Implement "Set Visibility" action to add contacts and set seesMe property - Add success notifications with count of affected members - Disable "Set Visibility" button when no members are selected - Use notification callbacks for data refresh - Hide "Set Visibility" buttons when no members need visibility settings - Add proper dialog state management and cleanup - Ensure dialog closes before triggering data refresh to prevent stale states The implementation provides a smooth user experience for managing member visibility settings with proper state synchronization between components.
jose added 4 commits 2025-10-14 13:23:09 +00:00
WIP: mockup for set visibility dialog acf7d611e8
WIP: meeting members adjustments 461ee84d2a
WIP: button and icon additions b84546686a 
- Mirrored "Refresh" and "Visibility" buttons on top and bottom of member list
- Added back info icons for list actions
- When clicked, Person icon shows informative notification
feat: implement member visibility dialog with checkbox selection and refresh 07b538cadc 
- Add "Set Visibility" dialog for meeting members who need visibility settings
- Filter members to show only those not in contacts or without seesMe set
- Implement checkbox selection with "Select All" functionality
- Add reactive checkbox behavior with proper state management
- Default all checkboxes to checked when dialog opens
- Implement "Set Visibility" action to add contacts and set seesMe property
- Add success notifications with count of affected members
- Disable "Set Visibility" button when no members are selected
- Use notification callbacks for data refresh
- Hide "Set Visibility" buttons when no members need visibility settings
- Add proper dialog state management and cleanup
- Ensure dialog closes before triggering data refresh to prevent stale states

The implementation provides a smooth user experience for managing member visibility settings with proper state synchronization between components.
jose added 1 commit 2025-10-15 12:25:09 +00:00
feat: add auto-refresh with countdown to MembersList ca545fd4b8 
- Auto-refresh members list every 10 seconds
- Display countdown timer in refresh buttons
- Manual refresh resets countdown to 10 seconds
jose changed title from WIP: feat: implement member visibility dialog with checkbox selection and refresh to feat: implement member visibility dialog with checkbox selection and refresh 2025-10-15 12:38:07 +00:00
jose commented 2025-10-15 12:45:07 +00:00
Author
Owner
Copy Link

@trentlarson it feels odd having the bulk of the contact- and visibility-setting functionality in App instead of MembersList. Is there a better way around it, or is this acceptable?

@trentlarson it feels odd having the bulk of the contact- and visibility-setting functionality in `App` instead of `MembersList`. Is there a better way around it, or is this acceptable?
jose added 2 commits 2025-10-16 13:15:47 +00:00
refactor: extract SetVisibilityDialog into standalone component ea19195850 
- Extract "Set Visibility to Meeting Members" dialog from App.vue into dedicated SetVisibilityDialog.vue component
- Move dialog logic directly to MembersList.vue for better component coupling
- Remove unnecessary intermediate state management from App.vue
- Clean up redundant style definitions (rely on existing Tailwind CSS classes)
- Remove unused logger imports and debug functions
- Add explanatory comment for Vue template constant pattern

This improves maintainability by isolating dialog functionality and follows established component patterns in the codebase.
feat: pause auto-refresh when SetVisibilityDialog is open e3598992e7 
- Pause auto-refresh when SetVisibilityDialog becomes visible
- Resume auto-refresh when dialog is closed
- Prevents background refresh interference during visibility settings
- Fix type compatibility for visibilityDialogMembers data structure

This ensures users can interact with the visibility dialog without
the members list refreshing in the background, providing a better
user experience for setting member visibility preferences.
trentlarson commented 2025-10-17 01:26:34 +00:00
Owner
Copy Link

@trentlarson it feels odd having the bulk of the contact- and visibility-setting functionality in App instead of MembersList. Is there a better way around it, or is this acceptable?

Hah! We were thinking the exact same thing. 👏

> @trentlarson it feels odd having the bulk of the contact- and visibility-setting functionality in `App` instead of `MembersList`. Is there a better way around it, or is this acceptable? Hah! We were thinking the exact same thing. 👏
trentlarson reviewed 2025-10-17 01:44:07 +00:00
src/App.vue Outdated
@@ -381,0 +390,4 @@
// eslint-disable-next-line @typescript-eslint/no-explicit-any
const activeIdentity = await (this as any).$getActiveIdentity();
this.activeDid = activeIdentity.activeDid || "";
}
trentlarson commented 2025-10-17 01:44:07 +00:00
Owner
Copy Link

Since these are not used, I don't see any reason to add this section.

This might make these variables accessible in other components and your intent may be to load them in one place, which makes sense. However, I do see a few potential side-effects that I don't love:

  1. There are multiple DB "settings" loads in many of these places (one here and and another in each specific View), so we would want to remove all the other loads to avoid so many DB loads.

  2. If there are errors in the DB accesses, that shuts down the whole app, and I believe some pages like Help should have almost no logic so that people can get there even if errors happen elsewhere. (Maybe there are "catch" statements so that doesn't happen... I'd have to look.)

  3. The variables are a bit magic: when you're in another class, it's hard to know from where these values are loaded. (It may still be worthwhile if it saves user error in all these places. Will ponder.)

So I look forward to your thoughts... if you think it's worthwhile, let me know... and we'd want to work on issue #1 across the codebase, so it might be worthwhile in a separate PR.

Since these are not used, I don't see any reason to add this section. This might make these variables accessible in other components and your intent may be to load them in one place, which makes sense. However, I do see a few potential side-effects that I don't love: 1) There are multiple DB "settings" loads in many of these places (one here and and another in each specific View), so we would want to remove all the other loads to avoid so many DB loads. 2) If there are errors in the DB accesses, that shuts down the whole app, and I believe some pages like Help should have almost no logic so that people can get there even if errors happen elsewhere. (Maybe there are "catch" statements so that doesn't happen... I'd have to look.) 3) The variables are a bit magic: when you're in another class, it's hard to know from where these values are loaded. (It may still be worthwhile if it saves user error in all these places. Will ponder.) So I look forward to your thoughts... if you think it's worthwhile, let me know... and we'd want to work on issue #1 across the codebase, so it might be worthwhile in a separate PR.
jose commented 2025-10-17 09:05:50 +00:00
Author
Owner
Copy Link

Thanks for catching this. It's leftover code from when the rest of the logic was housed in here. I'll clean that up.

Thanks for catching this. It's leftover code from when the rest of the logic was housed in here. I'll clean that up.
trentlarson reviewed 2025-10-17 01:47:09 +00:00
src/components/SetVisibilityDialog.vue Outdated
@@ -0,0 +1,333 @@
<template>
trentlarson commented 2025-10-17 01:47:09 +00:00
Owner
Copy Link

I vote for one more descriptive word to say that this is a bulk action dialog... like SetBulkVisibilityDialog or SetMeetingVisibilityDialog or SetMultipleVisibilityDialog

I vote for one more descriptive word to say that this is a bulk action dialog... like SetBulkVisibilityDialog or SetMeetingVisibilityDialog or SetMultipleVisibilityDialog
jose commented 2025-10-17 09:08:06 +00:00
Author
Owner
Copy Link

SetBulkVisibilityDialog is perfect. I'll make the change.

`SetBulkVisibilityDialog` is perfect. I'll make the change.
jose added 1 commit 2025-10-17 11:17:15 +00:00
refactor: rename SetVisibilityDialog to SetBulkVisibilityDialog and remove unused code 4de4fbecaf 
- Rename SetVisibilityDialog.vue to SetBulkVisibilityDialog.vue for better clarity
- Update all component references in MembersList.vue (import, registration, template usage)
- Update component class name from SetVisibilityDialog to SetBulkVisibilityDialog
- Rename calling function name to showSetBulkVisibilityDialog to match class name change
- Remove unused properties and created() method from App.vue

This cleanup removes dead code and improves component naming consistency.
jose added 1 commit 2025-10-17 13:15:27 +00:00
feat: auto-show visibility dialog for meeting members 4f3a1b390d 
- Show dialog on initial load if members need visibility settings
- Show dialog during auto-refresh only when new members are added (not removed)
- Show dialog on manual refresh if any members need visibility settings
- Remove manual "Set Visibility" buttons from UI as dialog now appears automatically
- Add logic to track previous visibility members and detect changes
- Improve UX by proactively prompting users to set visibility for new meeting members

The dialog now appears automatically in these scenarios:
- Component initialization with members needing visibility
- Auto-refresh when new members join the meeting
- Manual refresh when members need visibility settings
jose merged commit 1ce7c0486a into master 2025-10-21 08:52:15 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
trentlarson
Labels
No items
No Label
Milestone
No items
No Milestone
Assignees
Clear assignees
anomalist jose jsnbuchanan kentbull trentlarson
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: trent_larson/crowd-funder-for-time-pwa#208
Delete Branch "meeting-members-set-visibility"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?