r15-software-dev/scholarships-rs

0 Fork 0

Implement provider scholarship edit form #33

Merged

BobdaFett merged 10 commits from feature/scholarship-edit-form into main

2025-12-22 17:49:27 +00:00

BobdaFett commented

2025-12-19 17:48:47 +00:00

(Migrated from github.com)

Creates a new scholarship edit form, which should be accessed from the provider dashboard. Requires providers to be signed in.

Assuming the provider is signed in, the application will present the provider with a list of scholarships that they own personally. They can choose to edit or delete each scholarship, along with the choice to create a new one.

Creating a new scholarship requires the server to "register" a new entry in the scholarships table. It then signals the client side to refetch the data. It also returns the ID of the new scholarship should we want to do anything with it.

As a side note, this PR also introduces a small change to the loaner application - it will now redirect to the main page after checking a loaner back in, instead of refetching the list of students. This should lower the number of database requests that the app is making.

Creates a new scholarship edit form, which should be accessed from the provider dashboard. Requires providers to be signed in. Assuming the provider is signed in, the application will present the provider with a list of scholarships that they own personally. They can choose to edit or delete each scholarship, along with the choice to create a new one. Creating a new scholarship requires the server to "register" a new entry in the scholarships table. It then signals the client side to refetch the data. It also returns the ID of the new scholarship should we want to do anything with it. As a side note, this PR also introduces a small change to the loaner application - it will now redirect to the main page after checking a loaner back in, instead of refetching the list of students. This should lower the number of database requests that the app is making.

meraghon (Migrated from github.com) reviewed

2025-12-19 17:48:47 +00:00

meraghon (Migrated from github.com) requested changes

2025-12-19 19:09:36 +00:00

src/pages/api/scholarships.rs

						
				@@ -92,0 +177,4 @@

				    match client

				        .delete_item()

				        .table_name("leptos-scholarship-test")

				        .key("subject", AttributeValue::S(scholarship_id))

meraghon (Migrated from github.com) commented

2025-12-19 18:14:28 +00:00

Ensure that no two scholarships can have the same name.

Ensure that no two scholarships can have the same name.

src/pages/scholarship_info.rs

						
				@@ -7,3 +1,1 @@

				use crate::components::{

				    ActionButton, ChipsList, Loading, OutlinedTextField, Panel, RadioList, Row,

				};

				use leptos::either::Either;

meraghon (Migrated from github.com) commented

2025-12-19 18:30:56 +00:00

Add confirmation before deleting a scholarship to prevent accidental deletion.

Add confirmation before deleting a scholarship to prevent accidental deletion.

src/pages/scholarship_info.rs

						
				@@ -131,0 +363,4 @@

				            SubmitStatus::Sending => "Sending submission...".into(),

				            SubmitStatus::Success => "Success".into(),

				            SubmitStatus::Error(msg) => format!("Error: {}", msg),

				        }

meraghon (Migrated from github.com) commented

2025-12-19 18:27:43 +00:00

of created scholarship doesn't update after submit.

<no name found> of created scholarship doesn't update after submit.

src/pages/scholarship_info.rs

meraghon (Migrated from github.com) commented

2025-12-19 18:24:34 +00:00

Update the scholarship list after the user submits

Update the scholarship list after the user submits

meraghon (Migrated from github.com) commented

2025-12-19 18:25:32 +00:00

The list is never told to refresh after “Submit” (create/update), because the ScholarshipList resource lives inside ScholarshipList() and the submit_action lives inside ScholarshipForm(). They don’t share a refresh signal.

The list is never told to refresh after “Submit” (create/update), because the ScholarshipList resource lives inside ScholarshipList() and the submit_action lives inside ScholarshipForm(). They don’t share a refresh signal.

BobdaFett (Migrated from github.com) reviewed

2025-12-21 18:39:28 +00:00

src/pages/api/scholarships.rs

						
				@@ -92,0 +177,4 @@

				    match client

				        .delete_item()

				        .table_name("leptos-scholarship-test")

				        .key("subject", AttributeValue::S(scholarship_id))

BobdaFett (Migrated from github.com) commented

2025-12-21 18:39:28 +00:00

This is a whole issue in itself - Dynamo doesn't support checking this information against the whole table simply. From what I've read, the best approach to this requires creating a whole new table that contains "name lock" information, literally all the names of the scholarships that have already been used. This could require a significant rewrite of the database functions.

I'm going to create this as a separate issue. Right now, this approach works, although it does allow duplicate names. That's alright, as we've got at least a functional mechanism. I will handle the overarching server function rewrite another time, after this component is finished.

We'll have to discuss the best approach for that as well - sometimes the best thing to do would actually be using the scholarship's name as the primary key. This is enforced as unique all the time, but I personally think that's not our desired behavior because of the structure of our ExpandableInfo struct - the subject field is always a UUID, while the rest of the information is stored in the struct's HashMap<String, ValueType>.

This is a whole issue in itself - Dynamo doesn't support checking this information against the whole table simply. From what I've read, the best approach to this requires creating a whole new table that contains "name lock" information, literally all the names of the scholarships that have already been used. This could require a significant rewrite of the database functions. I'm going to create this as a separate issue. Right now, this approach works, although it does allow duplicate names. That's alright, as we've got at least a functional mechanism. I will handle the overarching server function rewrite another time, after this component is finished. We'll have to discuss the best approach for that as well - sometimes the best thing to do would actually be using the scholarship's name as the primary key. This is enforced as unique all the time, but I personally think that's not our desired behavior because of the structure of our `ExpandableInfo` struct - the subject field is always a UUID, while the rest of the information is stored in the struct's `HashMap<String, ValueType>`.

BobdaFett commented

2025-12-22 03:11:57 +00:00

(Migrated from github.com)

The styling of the modal isn't quite there, but I plan on making a modal window component that we can use across all pages. This means I won't have to keep creating the same modal dialog over and over.

The styling of the modal isn't quite there, but I plan on making a modal window component that we can use across all pages. This means I won't have to keep creating the same modal dialog over and over.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: r15-software-dev/scholarships-rs#33