github-starred/vikunja
2
0
Fork 0
mirror of https://github.com/go-vikunja/vikunja.git synced 2026-05-06 11:37:49 -05:00
Code Issues 690 Packages Projects Releases 11 Wiki Activity

Feature Request: Sync avatar from OpenID providers #2231

New Issue
Closed
opened 2026-03-22 13:58:21 -05:00 by GiteaMirror · 5 comments
GiteaMirror commented 2026-03-22 13:58:21 -05:00
Owner
Copy Link

Originally created by @maggch97 on GitHub (May 22, 2025).

Description

Latest unstable vikunja does not allow the OpenID user to change name because it's from provider, but avatar is allowed to be changed. I check the code, LDAP user's avatar is auto synced.
Would it be ok if I open a PR to do same thing for OpenID users, auto sync the avatar from provider?

Vikunja Version

unstable

Browser and version

No response

Can you reproduce the bug on the Vikunja demo site?

Please select

Screenshots

No response

Originally created by @maggch97 on GitHub (May 22, 2025). ### Description Latest unstable vikunja does not allow the OpenID user to change name because it's from provider, but avatar is allowed to be changed. I check the code, LDAP user's avatar is auto synced. Would it be ok if I open a PR to do same thing for OpenID users, auto sync the avatar from provider? ### Vikunja Version unstable ### Browser and version _No response_ ### Can you reproduce the bug on the Vikunja demo site? Please select ### Screenshots _No response_
GiteaMirror commented 2026-03-22 13:58:22 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (May 22, 2025):

Sure, would love a PR!

@kolaente commented on GitHub (May 22, 2025): Sure, would love a PR!
GiteaMirror commented 2026-03-22 13:58:22 -05:00
Author
Owner
Copy Link

@maggch97 commented on GitHub (May 22, 2025):

Sure, would love a PR!

I would like to discuss the implementation. The OpenID provider will return a picture url when a user login, here we have 3 method to deal with the url

  1. Download image from the url, then process like ldap. To avoid download a same image multiple times, we need to add a new field externalAvatarUrl. This method will cost more time to login.
  2. Just save the picture url in a new field externalAvatarUrl, then redirect /api/v1/avatar to the external url. This method reduces the server load and does not cause any performace issue. But we cannot return an image of the specified size.
  3. Based on 2, We can add a new avatar API that does not allow for specifying the size and returns externalAvatarUrl. But for an avatar, this is a bit overly complicated.

Which method do you prefer?

@maggch97 commented on GitHub (May 22, 2025): > Sure, would love a PR! I would like to discuss the implementation. The OpenID provider will return a picture url when a user login, here we have 3 method to deal with the url 1. Download image from the url, then process like ldap. To avoid download a same image multiple times, we need to add a new field `externalAvatarUrl`. This method will cost more time to login. 2. Just save the picture url in a new field `externalAvatarUrl`, then redirect /api/v1/avatar to the external url. This method reduces the server load and does not cause any performace issue. But we cannot return an image of the specified size. 3. Based on 2, We can add a new avatar API that does not allow for specifying the size and returns externalAvatarUrl. But for an avatar, this is a bit overly complicated. Which method do you prefer?
GiteaMirror commented 2026-03-22 13:58:22 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (May 22, 2025):

Don't we always need to fetch the image to check if it changed? I wouldn't assume the url changes when the avatar changes.

Another option would be a cache of sorts. But in general, since we're talking about two servers talking to each other, I'd assume fetching the image is fast and does not incur much overhead. Did you check how much the overhead is?

@kolaente commented on GitHub (May 22, 2025): Don't we always need to fetch the image to check if it changed? I wouldn't assume the url changes when the avatar changes. Another option would be a cache of sorts. But in general, since we're talking about two servers talking to each other, I'd assume fetching the image is fast and does not incur much overhead. Did you check how much the overhead is?
GiteaMirror commented 2026-03-22 13:58:22 -05:00
Author
Owner
Copy Link

@maggch97 commented on GitHub (May 22, 2025):

Don't we always need to fetch the image to check if it changed? I wouldn't assume the url changes when the avatar changes.

Another option would be a cache of sorts. But in general, since we're talking about two servers talking to each other, I'd assume fetching the image is fast and does not incur much overhead. Did you check how much the overhead is?

No, I didn't observe any performace issue with https://github.com/go-vikunja/vikunja/pull/821. If you don't have any concerns about this implementation , I'm fine with it too. We can optimize it later if we get any user feedback about performance issues.

@maggch97 commented on GitHub (May 22, 2025): > Don't we always need to fetch the image to check if it changed? I wouldn't assume the url changes when the avatar changes. > > Another option would be a cache of sorts. But in general, since we're talking about two servers talking to each other, I'd assume fetching the image is fast and does not incur much overhead. Did you check how much the overhead is? No, I didn't observe any performace issue with https://github.com/go-vikunja/vikunja/pull/821. If you don't have any concerns about this [implementation ](https://github.com/go-vikunja/vikunja/pull/821), I'm fine with it too. We can optimize it later if we get any user feedback about performance issues.
GiteaMirror commented 2026-03-22 13:58:23 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (May 23, 2025):

If there are no real performance implications, I think we're good with changing this later if we see problems in the wild.

@kolaente commented on GitHub (May 23, 2025): If there are no real performance implications, I think we're good with changing this later if we see problems in the wild.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
area/attachments
area/auth
area/avatars
area/backup-restore
area/caldav
area/calendar-view
area/comments
area/config
area/database
area/desktop
area/docker
area/email
area/favorites
area/filters
area/frontend
area/gantt
area/i18n
area/import-export
area/internal-code
area/kanban
area/labels
area/list-view
area/mobile
area/notifications
area/permissions
area/projects
area/pwa
area/recurring-tasks
area/reminders
area/search
area/shortcuts
area/subtasks
area/sync
area/table-view
area/task-editor
area/task-metadata
area/task-relations
area/teams
area/theming
area/time-tracking
area/typesense
area/views
area/webhooks
bug
changes requested
concern/accessibility
concern/performance
concern/regression
concern/ux
confirmed
db/mysql
dependencies
enhancement
good first issue
help wanted
integration/inbound
integration/outbound
kind/bug
kind/feature
needs reproduction
pull-request
Mirrored from GitHub Pull Request
 question
security
support
upstream issue
waiting for reply
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vikunja#2231
Delete Branch "%!s()"

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?