Uh oh!
There was an error while loading. Please reload this page.
fix(proposals): confirm before accepting a talk proposal - #308
Merged
Conversation
"Accept and Create Talk" fired on a single click and did real work: it creates an Event Talk and, for every speaker without an account, a User and a Speaker Profile. Move it into the Actions dropdown and put a confirmation in front of it. The status change moves server-side into create_talk. It used to happen in the browser as an un-awaited frm.save() followed straight away by frm.refresh() and a route change, which left two responses racing: the second one hit frappe.hide_msgprint() while the first dialog was still fading out, and the late hidden.bs.modal handler emptied the dialog body after the new message had been appended. The visible result was a blank "Message" box. Doing both writes in one request removes the race, and makes the two writes atomic -- previously a failed save left the talk created but the proposal still un-accepted, and the retry hit "Talk already created for this proposal!" with no way forward. Speaker Users are now created as Website Users. They sign in to the dashboard, not the desk, same as the booking flow. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
Contributor
Successfully created backport PR for |
Emmafidelis pushed a commit
to Emmafidelis/buzz
that referenced
this pull request
Aug 2, 2026
fix(proposals): confirm before accepting a talk proposal (bwhtech#308) "Accept and Create Talk" fired on a single click and did real work: it creates an Event Talk and, for every speaker without an account, a User and a Speaker Profile. Move it into the Actions dropdown and put a confirmation in front of it. The status change moves server-side into create_talk. It used to happen in the browser as an un-awaited frm.save() followed straight away by frm.refresh() and a route change, which left two responses racing: the second one hit frappe.hide_msgprint() while the first dialog was still fading out, and the late hidden.bs.modal handler emptied the dialog body after the new message had been appended. The visible result was a blank "Message" box. Doing both writes in one request removes the race, and makes the two writes atomic -- previously a failed save left the talk created but the proposal still un-accepted, and the retry hit "Talk already created for this proposal!" with no way forward. Speaker Users are now created as Website Users. They sign in to the dashboard, not the desk, same as the booking flow. (cherry picked from commit 063e518) Co-authored-by: Harsh Tandiya <harsh.tandiya@gmail.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Accept and Create Talksat in the primary button bar and fired on a single click. It is not a cheap action: it creates an Event Talk and, for every speaker without an account, a User and a Speaker Profile. One stray click made records that are annoying to unwind. Now it lives underActionsbehind a confirmation.While testing the confirm, an empty "Message" dialog showed up after clicking Yes. Two things were going on:
frm.save()without awaiting it, thenfrm.refresh(), thenset_route. Two responses ended up in flight together. The second one callsfrappe.hide_msgprint()while the first dialog is still fading, andhidden.bs.modalfires late — after the new message has been appended — soonhideempties the body of an already-visible dialog. Blank box, title "Message", blue dot.So the status change moved into
create_talkserver-side and the handler is now just call → toast → route. No overlapping requests, no race. It also makes the two writes atomic: before, a failedfrm.save()left the talk created but the proposal un-accepted, and the retry hitTalk already created for this proposal!with no way out.Speaker Users are now created as Website Users, matching
get_or_create_guest_userin the booking flow — they sign in to the dashboard, not the desk. This also stops the "No Roles Specified" msgprint, which only fires for System Users. The welcome email is unchanged and still sent.Not changed: the
frappe.hide_msgprint/hidden.bs.modalrace is a Frappe core bug. Worth an upstream issue, not patched here.Tests: 3 new ones covering the status flip, the Website User type, and that a second
create_talkraises without leaving a second Event Talk behind. 10 pass in the module.🤖 Generated with Claude Code