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

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

Open
jose wants to merge 9 commits from meeting-members-set-visibility into master
Conversation 2 Commits 9 Files Changed 6
jose commented 4 days ago
Owner
  • 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 4 days ago
b84546686a WIP: button and icon additions
07b538cadc feat: implement member visibility dialog with checkbox selection and refresh
jose added 1 commit 3 days ago
ca545fd4b8 feat: add auto-refresh with countdown to MembersList
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 3 days ago
jose commented 3 days ago
Poster
Owner

@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 2 days ago
ea19195850 refactor: extract SetVisibilityDialog into standalone component
e3598992e7 feat: pause auto-refresh when SetVisibilityDialog is open
trentlarson commented 2 days ago
Owner

@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 2 days ago
src/App.vue Outdated
// eslint-disable-next-line @typescript-eslint/no-explicit-any
const activeIdentity = await (this as any).$getActiveIdentity();
this.activeDid = activeIdentity.activeDid || "";
}
trentlarson commented 2 days ago
Poster
Owner

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 2 days ago
Poster
Owner

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 2 days ago
src/components/SetVisibilityDialog.vue Outdated
<template>
trentlarson commented 2 days ago
Poster
Owner

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 2 days ago
Poster
Owner

SetBulkVisibilityDialog is perfect. I'll make the change.

`SetBulkVisibilityDialog` is perfect. I'll make the change.
jose added 1 commit 1 day ago
4de4fbecaf refactor: rename SetVisibilityDialog to SetBulkVisibilityDialog and remove unused code
jose added 1 commit 1 day ago
4f3a1b390d feat: auto-show visibility dialog for meeting members
This pull request can be merged automatically.
You are not authorized to merge this pull request.
Sign in to join this conversation.
Reviewers
Request review
No reviewers
Labels
Apply labels
Clear labels
No items
No Label
Milestone
Set milestone
Clear milestone
No items
No Milestone
Assignees
Assign users
Clear assignees
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Write Preview
Loading…
Cancel
Save
There is no content yet.
Delete Branch 'meeting-members-set-visibility'

Deleting a branch is permanent. It CANNOT be undone. Continue?

No
Yes