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

Added #15015 - ability for admins to select default avatar #15027

Merged
merged 15 commits into from
Jul 4, 2024

Conversation

snipe
Copy link
Owner

@snipe snipe commented Jul 4, 2024

This allows the admin to upload their own default avatar, or leave one out entirely.

I had to mark the tests here as incomplete, unfortunately, since the UploadedFile::fake()->image('logo.jpg') doesn't seem to return a "real" fake image, which means our image upload handler skips over it, so the settings table never gets updated with the returned value. I may keep working on this, but perhaps on Monday we can try to see if there's a workaround. (I tried using ->createWithContent() and doing a file_get_contents() of one of the demo images that's already in the public root, but no luck.) I'm loathe to refactor that image handler, but perhaps that's how we have to go. It all works fine in the GUI, it's just the way the UploadedFile mock works that's a real pain to work around for testing.

Screen.Recording.2024-07-04.at.5.03.14.PM.mov

So the way it currently works,

  1. If you have "load remote scripts" enabled in your admin settings, you'll get switched over to gravatar from our built-in default avatar.
  2. If you don't have "load remote scripts" enabled, you'll still see our old familiar smiley default avatar
  3. If you upload your own default avatar, you'll see your own default avatar image
  4. If you have no default image uploaded and you don't have remote script loading enabled, no avatar will be displayed
  5. Individual users who have avatars uploaded will always take precedence over the above mentioned options

Fixes #15015.

Copy link

what-the-diff bot commented Jul 4, 2024

PR Summary

  • Refactored the logic for loading remote user avatars
    In our primary user settings, the function to load remote avatars has been improved. Instead of forcing this function to be active, users can now opt in or out.

  • Introduced default user avatars
    We've made enhancements to our user avatar system. If a user doesn't have a custom avatar, a default one will be provided. We've even included a section for uploading this default avatar in our branding settings.

  • Test methods updated for various features
    To ensure these changes work as expected, we have updated numerous automated tests. These tests cover scenarios like site name validation, successfully saving a site name, logo upload and deletion, email logo upload and deletion, as well as processes related to label logos and favicons.

  • Migration to add new default_avatar column
    In line with the new feature, our settings data table will now include a new column for storing the default avatar. This is managed by a new migration file.

  • Revised labels and icons
    To improve user understanding, we've revised labels and icons throughout the system. The term "Use Gravatar" has been replaced with "Load Remote Avatars". The user avatar icon has also been modified to be more indicative.

  • Updated settings UI
    We've refined our settings pages to match our new features. Now, there is an area for uploading the default avatar in the branding settings and a checkbox for deciding whether to load remote avatars.

@snipe snipe merged commit edd6170 into develop Jul 4, 2024
9 checks passed
@snipe snipe deleted the feature/sc-26112/allow_default_avatar branch July 4, 2024 16:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant