| WebSockets | - all interactions between frontend and backend should happen via WebSockets instead of HTTP
- updates made in one tab or a browser should be reflected in another tab or a browser immediately, without page refreshing
| Yes |
| Full Auth | - registration with sending a confirmation link via email
- password recovery with sending a recovery link via email bound to the account
- during account creation a user chooses a secret question and answers on it
- during password recovery a user should answer on the secret question correctly
- stored passwords are hashed and salted
- backend creates and stores sessions with expiration time
- session tokens are used for frontend-backend communications
- session tokens are stored as cookies on frontend
| if Spring Security is fully utilized |
| Context Search | - a user can find the most similar needs for some need or needs (come up with a specific context. E.g., needs similar to what a helper has in their basket)
- can be done by user request or offered by the system automatically in some situations
- needs should have at least descriptions in addition to names to give more data for similarity evaluation
- usage of embeddings is expected
- choice of the most fitting similarity metric with a justification is expected
- usage of a vector database with HNSW or IVF indices and an ability to explain how it works gives the second extra credit
| Yes |
| Dockerization | - backend and frontend are put into separate Docker images
- backend data is persistent via a mounted folder
- docker images are multi-stage to minimize the image size
- networking is set properly so frontend and backend containers can communicate
- Docker Compose is used to orchestrate backend and frontend launch
- dockerization is not implemented by just one person
| Yes |
| Relational Database | - file(-s) as a data storage is replaced with PostgreSQL or MySQL
- the data access layer is rewritten with Spring Data JPA and derived method queries (and Hibernate functionality if needed)
- standard Spring Data JPA interfaces such as CrudRepository or JpaRepository are used
- migration is not implemented by one person
| Yes |
| AI Chatbot | - a helper can chat with a chatbot about anything related to the non-profit main theme
- a chatbot should have actual information about all needs at every moment of a dialog
- a chatbot should not discuss anything outside of these topics
- a manager can create, edit and delete different personalities for a chatbot, each of them should have a name
- a helper can choose a specific chatbot personality from available ones
- system prompt usage is expected
| Yes |
| AI-assisted Need Generation | - a manager has an interface where they can describe a need in a free form and submit it to a LLM
- LLM should provide a structured need based on the provided description
- a manager should be able to review, edit and approve or reject the proposed need
- in case of approval, the need is added to the standard list
- in case of rejection, the system will try to regenerate a need, and a manager should have an option to communicate to LLM what was wrong
| Yes |
| AI-generated Illustrations | - when a manager creates a need, they should be able to ask an AI to generate the most fitting image for the need based on its content
- when an image is generated, a manager can approve or reject it
- in case of approval, the need with the generated image is added to the standard list
- in case of rejection, the system will try to regenerate an image, and a manager should have an option to communicate to AI what was wrong
| Yes |
| AI-evaluated Survey | - a manager can create and edit a survey with a list of questions (types of the questions are up to the team)
- a helper can fill the survey and based on the answers a LLM will offer the most fitting items (e.g., a specific dog breed for adoption)
| Yes |
| Dynamic Reports | - at least five different parametrized reports (a user can select different values to change report data selection dynamically - dates, types, etc.)
- each report is shown as a plot
- there are at least three different plot types
- use of plot-generating frontend libraries is implied
| No |
| Messaging Subsystem | - all helpers and a manager can send messages to each other with a preserved history
- helpers and a manager can create group discussions and add any other user to those discussions
- a user can see a list of discussions (group and individual) they are participating in and select which one to read and write to
- a user can leave a group discussion
- users cannot read discussions they are not a part of even if they know the discussion URL
- users receive notifications about messages in their discussions (group and individual) with a link to that specific discussion
| No |
| Loyalty Subsystem | - helpers can earn loyalty points for their contributions
- a helper can spend loyalty points by buying badges in a badge shop
- anybody can see a list of helpers and their profiles with badges
- a helper can hide or unhide badges visible in their profile
| No |
| Event Calendar | - a manager can create, edit and delete events with at least a name, date, time, location and description
- each event requires a number of volunteers
- helpers can see all the events and filter them by several criteria
- events can be seen as a list and as an embedded map (Google Maps, OpenStreetMap, etc.) with clickable pins showing some details
- regardless of the event set view, a helper can click on a link / button for each event that will lead to an event page with all the details
- a helper can commit to an event as a volunteer or remove their commitment
- a helper can see all events they committed for
- as soon as the number of required volunteers for an event is reached, helpers cannot commit
- if an event is edited or deleted, all committed volunteers should be notified
| No |
| Appointment Scheduling | - a helper can choose a date and a time when they want to meet with a manager in a standard calendar-like interface
- a meeting can take 15, 30, 45 or 60 minutes by helper's choice
- a helper can write down a description / reason for the meeting
- a helper can see when the manager is available or not based on existing appointments, but cannot see any details of those appointments
- a manager can approve or reject appointment requests - in both cases the helper will receive an email
- a manager can see their calendar in the same way as helpers but all the appointment details are visible
- a helper can cancel or edit an appointment, in this case the manager will receive an email
| No |
| Blog Subsystem | - a helper can create a blog where they can post messages
- any user can leave comments under a blog post
- any helper (except the blog owner) can subscribe for a blog - they will receive email notifications when a new post or a comment is published)
- a blog owner can delete or edit any post from their blog
- any user can delete or edit their own comments
- a manager can delete or edit any post or comment
- a website has a feed of all blog posts in chronological order with pagination
| No |
| Advertisement Campaigns | - a manager can create an advertisement campaign with a set of criteria, sequence of messages, a start date & time and a delay
- the system automatically filters helpers that should receive messages based on the criteria at the moment of message sending
- the system will start sending messages to filtered users at the set date & time
- the first message will be sent immediately, the next one after a delay, the third one after a delay x2, and so on
- a manager can see a list of campaigns, each campaign with the history of sent messages and a list of helpers who received each message
- a manager can edit or delete a campaign at any moment
| No |
| Proposed Needs | - a helper can create a need draft that will be offered to a manager for approval
- all helpers can see currently not approved drafts
- any helper can vote for a draft, but only once per draft
- a manager can see the number of votes for every draft
- a manager can see all need drafts and can reject, edit and approve them
- as soon as a draft is approved, it's becoming a standard need
- a helper can see a list of their drafts that have been approved and rejected or are currently in consideration
- a manager can see a list of all drafts that have been approved or rejected or are currently in consideration
- search functionality is available for lists of drafts
| No |
| Payment Subscription | - a manager can create an ongoing donation campaign without a finite amount of money to be collected in total
- a helper has an account balance that can be topped up at any moment manually using a credit card
- a helper can subscribe for a donation campaign by choosing an amount of money that will be donated from their account every period of time
- if a helper's account doesn't have enough money when the system tries to charge it, the charge attempt will be failed and the helper will receive an email
- a helper can see their history of topping up the account
- a helper can see their history of charges for all or some specific donation campaigns
- a manager can see a history of donations for all or specific campaigns, and basic statistics (e.g., how much money were donated per day)
- a helper can unsubscribe from a campaign at any moment
- a manager can finish a campaign at any moment - in this case all subscribed helpers will receive an email
| No |
| Targeted Donations | - every need is connected to one or several organizations (e.g., schools)
- a manager can create, edit and remove organizations and connect them to needs
- a helper can see what are the organizations connected to each need
- when a helper donates to some specific need, they can select one or several connected to that need organizations that will benefit from this donation
- a manager should see donation statistics for organizations for each need and in total
| No |
| Cross-Helper Funding | - each helper has an account that can be topped up with a credit card
- a helper can send a request for funding to any other helper
- a helper can see all incoming funding requests and can choose which ones to fulfill
- if a helper chooses to fulfill a funding request, the corresponding amount of money will be transferred between accounts
- a helper can fund other helper without incoming requests
| No |