Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Email visibility option #41

Open
Lan2u opened this issue Jun 29, 2024 · 7 comments
Open

Email visibility option #41

Lan2u opened this issue Jun 29, 2024 · 7 comments
Assignees

Comments

@Lan2u
Copy link
Collaborator

Lan2u commented Jun 29, 2024

We don't consistently mask or not users emails.

Proposal:
As a makespace member I want to choose if my email should be visible to other makespace members so I have control over who can contact me.

As an admin/super-user I want to be able to see all emails used by makespace members so I can send emails about important/safety issues in line with our privacy policy.

@Lan2u
Copy link
Collaborator Author

Lan2u commented Jun 29, 2024

@chromy @erkannt thoughts on this one? Perhaps we should always mask for non-admins but sometimes I do want to message people privately / let them message me

@erkannt
Copy link
Collaborator

erkannt commented Jul 1, 2024

I like that. 'Show my email to other members' toggle?

@chromy
Copy link
Collaborator

chromy commented Jul 11, 2024

@Lan2u @erkannt For me I would be in favour of just always showing emails to Makespace members - although I admit I just put my email out in public which not everyone likes to do.

If we continue hide them there are some complicated edge cases to worry about.
Like probably trainers need to be able to see peoples emails on the equipment page if they've filled the form?
Otherwise it's hard to do the manual reconciliation / searching for misfiled forms.

As an alternative we could take the emails off the '/members' page but leave them on '/member/1234' etc that way there not all in a single giant list.

Also concerned that bugs like the one linked above will continue to occur till either it's built into the read model somehow (like emails are redacted at the point of fetching data depending on the actor doing the fetching or something) or we give up on hiding them.

@Lan2u
Copy link
Collaborator Author

Lan2u commented Jul 13, 2024

emails are redacted at the point of fetching data depending on the actor doing the fetching or something) or we give up on hiding them.

I think something of this type will probably be needed eventually anyway. We kinda have the same problem with all read models where we need to do isSuperUser or isTrainer etc. i.e. when getting equipment

@Lan2u
Copy link
Collaborator Author

Lan2u commented Jul 16, 2024

Assigning myself for an initial first pass (mvp) as part of #47

@chromy
Copy link
Collaborator

chromy commented Jul 22, 2024

Tried pushing the permissions back to the read model like this: 58fa478 let me know you thoughts.

@erkannt
Copy link
Collaborator

erkannt commented Jul 25, 2024

I like pulling this into read models. Keep renderers stupid and moves us toward once and only once for this concern.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Options
Development

No branches or pull requests

3 participants