Skip to content

Add unassign confirmation to UserDetail page. - #3231

Open
somiaj wants to merge 1 commit into
openwebwork:developfrom
somiaj:user-detail-unassign-confirm
Open

somiaj wants to merge 1 commit into
openwebwork:developfrom
somiaj:user-detail-unassign-confirm

Conversation

@somiaj

@somiaj somiaj commented Oct 4, 2026

Copy link
Copy Markdown
Contributor

Update the displayed information on the user detail page.

  • State how many sets a user is assigned to out of the total number.
  • Change the "edit class list data" link to a button.
  • Only show the "Assign All sets to Current User" button if the user isn't assigned to all sets, and state the user's name instead of "Current User".
  • Remove all the warnings from the page. Add a statement that unchecking the "Assigned" checkbox will unassign a set and cannot be undone.
  • Call the table "Available Sets", as it contains more sets than the ones assigned to the user.

Add a confirmation modal that appears whenever a set is unchecked to require confirmation. This also adds a hidden field so the unassign on the server side will only unassign if that hidden field had been updated to true.

Add a check to see if any of the dates were actually changed, and only update the database entry in the case a change was made to avoid unneeded database calls.

There was some logic which I believe was trying to allow a set date to be "0", but it wasn't working, param('x') && param('x') ne '' was being used, which I think was meant to allow "0", so the logic should have been defined param('x') && param('x') ne '', but the method checkDates was already explicitly disallowing a "0" date. Except for the checkDates method, the logic was all simplified to just checking for the truth of param('x'), since "0" was being disallowed in the checkDates check anyways.

Add a hidden save submit button first (if showing the assign all button), so pressing enter in the form will be a save and not an assign all action.

@somiaj
somiaj force-pushed the user-detail-unassign-confirm branch from 3da69ef to 29568ef Compare October 6, 2026 15:17
Update the displayed information on the user detail page.
+ State how many sets a user is assigned to out of the total number.
+ Change the "edit class list data" link to a button.
+ Only show the "Assign All sets to Current User" button if the
  user isn't assigned to all sets, and state the user's name
  instead of "Current User".
+ Remove all the warnings from the page. Add a statement that
  unchecking the "Assigned" checkbox will unassign a set and
  cannot be undone.
+ Call the table "Available Sets", as it contains more sets
  than the ones assigned to the user.

Add a confirmation modal that appears whenever a set is unchecked
to require confirmation. This also adds a hidden field so the
unassign on the server side will only unassign if that hidden
field had been updated to true.

Add a check to see if any of the dates were actually changed, and
only update the database entry in the case a change was made to
avoid unneeded database calls.

There was some logic which I believe was trying to allow a set date
to be "0", but it wasn't working, `param('x') && param('x') ne ''`
was being used, which I think was meant to allow "0", so the logic
should have been `defined param('x') && param('x') ne ''`, but
the method `checkDates` was already explicitly disallowing a "0"
date. Except for the `checkDates` method, the logic was all
simplified to just checking for the truth of `param('x')`, since
"0" was being disallowed in the `checkDates` check anyways.

Add a hidden save submit button first (if showing the assign all
button), so pressing enter in the form will be a save and  not an
assign all action.
@somiaj
somiaj force-pushed the user-detail-unassign-confirm branch from 29568ef to cb5d53c Compare October 6, 2026 18:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant