-
-
Notifications
You must be signed in to change notification settings - Fork 10.6k
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
Feature Request: User email address hide publicly #2330
Comments
closes TryGhost#2354 refs TryGhost#1641 - added addUnique() - added dropUnique() - added addColumn() -> needed for TryGhost#2330 - dropColumn() is missing due to lack of knex support - further cleanup of the migrations module
After some thought, and considering our default position is "don't add a setting unless you have to", I think we need to just remove |
Sounds like a better choice. If people want to provide an email address they can always do it via a page. |
Not sure - I can totally see themes using |
Apps will let people define all the custom fields they like, but we need to be pro privacy. We should make sure that |
Yes I think you're right given spam issues. My guess is that even if people do want to offer the ability to be contacted they'll prefer third party contact forms with captcha or social media links so emails don't get scraped by bots. |
closes TryGhost#2330 - added deletion email address from post.author in front end - updated tests - with some refactoring this could be done on API level
refs TryGhost#2330 - Pass through `options` to all toJSON calls on posts, tags, and users - Use options.context.user to determine whether it's OK to return user.email - Remove author.email handling code from frontend.js
refs TryGhost#2330 - Pass through `options` to all toJSON calls on posts, tags, and users - Use options.context.user to determine whether it's OK to return user.email - Remove author.email handling code from frontend.js
refs TryGhost#2330 - Pass through `options` to all toJSON calls on posts, tags, and users - Use options.context.user to determine whether it's OK to return user.email - Remove author.email handling code from frontend.js
Co-authored-by: Renovate Bot <bot@renovateapp.com>
At the moment we have the ability to user
{{author.email}}
in themes, which is great for creating amailto:
link if users would like it to be there.However if a user doesn't want their email address public and the theme they use shows it, they can't delete their address from the user settings field as it's required for notifications.
As such the options at present are:
{{author.email}}
tag to ensure privacyIt would be great if there were an option in the admin settings UI that a user could switch to determine whether a theme could access their email address or not.
That way themes could safely use the
{{author.email}}
tag to createmailto:
links for those who want them, without comprimising the privacy of those who don't.The text was updated successfully, but these errors were encountered: