UXPROD-36 Profile pictures

Owned by Kalibek Turgumbayev
Last updated: Mar 14, 2024
5 min read





Submitted

Sep 21, 2023 

Approved



Status

DONe

Impact

LOW

Arch Ticket

https://folio-org.atlassian.net/browse/ARCH-116

Prod ticket

https://folio-org.atlassian.net/browse/UXPROD-36



Glossary



Executive Summary

The purpose of the Patron Profile pictures feature in the Users App is to enable the secure storage, display, and management of profile photos for individual patrons within the FOLIO platform.

Requirements

Functional Requirements

Functional requirements are described in the UXPROD ticket

Non-Functional Requirements

Configurability:

  • Storage type for pictures should be configurable (e.g. database, S3-like storage)

Security: 

  1. Patron Profile Photos should be accessed by permissioned staff via the Users App.

  2. Authorized library staff can view and manage (upload, view, update, delete) photos for patron accounts.

Encryption:

  • Patron photos should be securely stored with proper encryption and access controls to protect sensitive information.

Performance:

  • 70K users/year 

  • FIle size limitation is 10MB per file. This is applicable for DB and Object storage. For externally linked profile pictures there can be no such limitation technically.

Assumptions

  1. External sources for profile pictures should have public access. No support for authentication/authorization mechanism is planned for such picture sources.

  2. No migration is required from previous sources of profile pictures

Target Architecture

The target solution implementation consists of the following:

  • Storage abstraction layer to allow configurability through environment variables. Storage interface must be implemented with read and write methods. Implementations in spring should be configured through @ConditionalOnProperty 

  • Following Object storage should be supported:

    • AWS S3 (for cloud installations)

    • Minio (for on-premise environments)

  • For database storage files should be encrypted with AES-256 algorithm, and object storage should support native encryption (minio, s3)

  • Thumbnails generation must be done during the upload process and persisted in the same storage as the pictures themselves

  • If the profile picture is provided as an external link, then the file should be uploaded and treated the same way as a regular file upload

Sequence diagram of profile picture upload:

Sequence diagram for fetching profile picture:

Profile Picture Compression

Option

Description

Pros

Cons

Decision

Option

Description

Pros

Cons

Decision

Frontend Compression

Library: https://www.npmjs.com/package/compressorjs

Approach: Compress profile pictures before sending it to backend

 

  • Easy to implement

  • Configurable compression ratio

  • Might not fit in future migration for big amount of profile pictures

Accepted

Backend Compression

Library: Maven Repository: jmagick » jmagick

Approach:

Compress profile pictures before persisting it in object storage/database

  • More configurable solution

  • Requires ImageMagick support in docker container

  • Might negatively affect upload performance

  • More network traffic

Postponed

Hardware Sizing

The hardware sizing is based on the number of new patrons per year provided by LoC. As the feature includes picture compression it is safe to use not max file size value but 1 MB. In the table below the max storage size is provided for different average file sizes.

Profile Picture Size

New users per year

1 year

3 years

5 years

Profile Picture Size

New users per year

1 year

3 years

5 years

10 MB

70000

700 GB

2.1 TB

3.5 TB

5 MB

350 GB

1.05 TB

1.75 TB

1 MB (most probable size)

70 GB

210 GB

350 GB

100 KB

7 GB

21 GB

35 GB

Open Questions

#

Question

Answered

Answer

#

Question

Answered

Answer

1

Do we need to store the original image?

Yes

@Amelia Sutton : no need to store the original image, only store the scaled image.

2

What scaled resolutions do we need to store?



@Amelia Sutton: TBD, 100x100 minimum

3

Does anyone use FOLIO from mobile browsers?





4

Do we maintain the picture after a user has expired? 

Yes

@Amelia Sutton: Yes

5

Do we support profile picture detention?

Yes

@Amelia Sutton: Yes

6

How thumbnails should be generated? Cropping or Resizing?



@Steve Ellis : Better to have a cropping mechanism on UI.

@Amelia Sutton : Resizing on the longer side with whitespace on the sides. Cropping might be a future feature

@Priyanka Terala : Cropping might require communication with Stripes core team. 

@Kalibek Turgumbayev : Let's estimate the cropping approach.

@Amelia Sutton : The SIG requests that images be scaled (without distortion) to fit within the space allotted in the relevant area of the UI. This would mean that there might be whitespace surrounding images that have a significant difference between their height and width, but will allow institutions to upload the images that they use in other systems without concern for adjusting for size. In the documentation for the profile pictures feature we will include recommended limits to aspect ratio that would not be enforced by the system. Even with this scaling it would be useful to allow images to be cropped using a cropping modal. So if you are able to find a React library that would allow for that to be implemented easily, it should be included in this initial feature.

7

File size limitations?

Yes

@Kalibek Turgumbayev : The recommended limitation is 10MB

@Amelia Sutton : UM SIG agrees to a 10MB limit

8

Should external links be stored in FOLIO?



@Amelia Sutton : No. One of the institutions has a requirement not to store pictures on FOLIO side. Detailed requirements should be investigated

@Steve Ellis : Cropping will not be possible.

@Amelia Sutton: As per Thomas Trutt at Cornell (the primary institution that requires external storage for profile pictures), for their externally hosted images they will be using SSL with a static token supplied in the url so we do not need any considerations for authentication by FOLIO for externally hosted images. 

9

Should FOLIO support any export of data related to profile pictures?



@Amelia Sutton : LOC and others will need functionality to migrate existing profile pictures from a previous system into FOLIO but this should be a separate feature. At the moment there is no requirement to allow export of profile picture data from FOLIO.

10

Do we need to support profile picture enabling on the fly? If yes, then it would be more complex than a single checkbox, because it will require providing storage type configuration



@Amelia Sutton : No, it is acceptable to have the settings to enable and disable profile pictures on the back-end without any UI components.

11

Hi @Amelia Sutton , 
In the Story UXPROD-36 its mentioned that - "Minimum accepted uploaded file type requirements: .heic .jpg .jpeg .png"

Question - Do we want to support .heic file type because HEIC is Apple's own format to store high resolution images made with iOS cameras. But I would store on backend JPG, because HEIC is not displayed in most browsers, not even in Safari. This will become an overhead in the implementation work. My suggestion is that lets take the minimalistic route (MVP) to accept images which are .jpg .jpeg .png type for the profile picture story. Your suggestions please.

CC: @Adesh Singh , @Irina Pokhylets , @Kalibek Turgumbayev and @Steve Ellis 



@Amelia Sutton : Yes, .heic handling can be moved to a future enhancement.