| Page Properties | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
columnIds | issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutioncolumns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution | issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution |
|
Glossary
Executive Summary
...
Non-Functional Requirements
Configurability:
Storage type for pictures should be configurable (e.g. database, S3-like storage)
Security:
Patron Profile Photos should be accessed by permissioned staff via the Users App.
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
External sources for profile pictures should have public access. No support for authentication/authorization mechanism is planned for such picture sources.
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
@ConditionalOnPropertyFollowing 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 |
|---|---|---|---|---|
Frontend Compression | Library: https://www.npmjs.com/package/compressorjs Approach: Compress profile pictures before sending it to backend |
|
| Accepted |
Backend Compression | Library: https://mvnrepository.com/artifact/jmagick/jmagick Approach: Compress profile pictures before persisting it in object storage/database |
|
| 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 |
|---|---|---|---|---|
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 |
|---|---|---|---|
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 , 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. |
|---|