feat: add affiliation attribute to user

[jaeyun0503]

What changes were proposed in this PR?

Summary

To gather more user information for a better overview of users, this PR introduces a new column affiliation to the user table. Now when a user logins to the Texera for the first time (after getting approved to REGULAR role), they will be prompted to enter their affiliation. The answer will be recorded to the database and retrieved when admins enter the admin dashboard.

For Developers

Please do the following steps to incorporate with new changes:

• Apply sql/updates/16.sql to your local postgres instance
• Run common/dao/src/main/scala/org/apache/texera/dao/JooqCodeGenerator.scala to generate jooq tables

Sample Video

Screen.Recording.2025-12-08.at.00.10.17.mov

Design of the Feature

When a user logins to the system for the first time, they will be prompted to enter their affiliation after getting approved to REGULAR role. The user can submit their affiliation and the frontend would send this information to the backend to save in the database. Users can choose to either enter the affiliation or skip the prompt and the system would remember if the user has been prompted or not by checking the user data from the database. Depending on the user's answer, the affiliation column would have different data (more details are included in "Backend Changes"). The system would only prompt once when the user logins to the system for the first time and would never ask again. To view the affiliation information, admins can go to the admin dashboard to view the affiliations of users.

Backend Changes

Introduced column affiliation to the user table. This column would have three types of entry:

1. null: Indicates the user has never been prompted before. Next time when the user logins to the system, they will be prompted to answer the affiliation question.
2. emptry string "": the user has been prompted and did not answer the affiliation question. This is to indicate that the user did not answer this question (whether by hitting the skip button, ESC, X, or pressing spaces outside of the prompt).
3. Actual value.
   16.sql adds the column to the user table and ensures the existing users' affiliation column is set to null. ddl file changed as well.

Added a UserResource.scala file to include the functions/apis related to retrieving & updating User data. Currently it only contains functions related to this PR, but in future other related functions can be added to this file as well.

Original user Schema

Proposed user Schema

Frontend Changes

Added the prompt window to pop up in the main page after logging in.
Added affiliation column to admin dashboard to cooperate with the new data.
Changed files that contain class User as new attribute affiliation is added to the class.

Any related issues, documentation, discussions?

Closes Issue #4118.

How was this PR tested?

Manually tested.

Was this PR authored or co-authored using generative AI tooling?

Generated-by: ChatGPT 5.1 (bug fixing)

[aicam]

@jaeyun0503 Could you please move the field to the already existing modal of send request when user register? this way admin can see the affiliation to know if they should approve or not

[jaeyun0503]

@jaeyun0503 Could you please move the field to the already existing modal of send request when user register? this way admin can see the affiliation to know if they should approve or not

I think this is a design question whether to use affiliation for one of the two purposes:

1. To identify the affiliation of users who want to use our system, or
2. To just gather more information from people who are using Texera.

If option 1, then we should go with your implementation so that every time when a new user comes into our system, the admin user can see their affiliation to decide whether to approve or not. If we choose option 2, then I think my implementation works fine since the affiliation part is collected once people are approved into the system. I think we should ask Professor Li to see which option seems better for our system.

[chenlica]

My general thought is that each user can provide their affiliation optionally, as some of them prefer not to provide such information. If the design is still not clear, we can do a short meeting and report the decision here.

[jaeyun0503]

My general thought is that each user can provide their affiliation optionally, as some of them prefer not to provide such information. If the design is still not clear, we can do a short meeting and report the decision here.

That aligns with my current design where users can optionally enter the affiliation at the very first time they log into the system. I think this PR is good for review.

[chenlica]

@aicam Please review it.

[aicam]

My biggest concern currently is the new field in User type, most of file changes in this PR are due to adding redundant null to all User objects