-
Notifications
You must be signed in to change notification settings - Fork 0
Capture amended and enhanced accounting #23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Capture amended and enhanced accounting
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry @Purplewells, your pull request is larger than the review limit of 150000 diff characters
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR is being reviewed by Cursor Bugbot
Details
You are on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle.
To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.
| } | ||
| } | ||
|
|
||
| base.BeforeSqlAction(args, result); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: Base BeforeSqlAction Called Twice, Validation Order Incorrect
The BeforeSqlAction method calls base.BeforeSqlAction twice (lines 151 and 178). The first call at line 151 happens before any validation logic, and the second call at line 178 happens after the validation logic for fee_collection_transaction_extra. This is incorrect because base.BeforeSqlAction should only be called once, and it should be called AFTER all custom validation logic has been executed. The comment at line 164 even states "Always call base AFTER your logic" but then the code violates this principle by calling base first at line 151. This could cause validation logic to be bypassed or executed in the wrong order.
| // Show a clear message to the user | ||
| result.ShowAlert("You do not have permission to delete payment records. Escalate to a higher authority."); | ||
| } | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: Redundant Delete Validation Blocks Cause Confusion
The delete validation for fee_collection_transaction_extra is duplicated with identical logic in two consecutive if blocks (lines 153-161 and lines 165-176). Both check the same condition (controller == "fee_collection_transaction_extra" && commandName == "Delete") and both check user roles. The first block only shows an alert without canceling the action, while the second block properly cancels the action with result.Canceled = true. This means the first block is redundant and could cause confusion. Only one of these blocks should exist, and it should properly cancel the action.
|
Capture amended and enhanced accounting |
Capture amended and enhanced accounting
Note
Adds a background queue worker, enhances fee refund processing and permissions, introduces a full assessment targets framework with pages/reports, and updates accounting/cashflow views and reports.
QueueWorker(runsusp_ProcessSyncQueue) andSyncQueueHelper; initialize inGlobal.asax.8.9.23.517.fee_collection_transaction_extra(newDueDate), refine UI, and restrict Delete toAdministrators.RefundReason,NameOfRecepient,ActionedBy) and addProcessMultiFeeRefundaction.TransactionTypeRefund(excludeREFUND) infee_collection_transaction.PaymentRecordsbank_manifestview and "Print To Current Bank" action.get_cashflow_inflow_outflowcontroller/page; update cashflow statements/reports.AssessmentTarget,TargetLevel,MeasurementType,MeasurementUnit,MeasurementTypeUnitMapping,TargetTemplate,TargetTemplateScope(+Detail),TargetEntity,TargetAssignment,TargetAdjustment, andWorkBenchAssessmentTargets.PersonOwner,IdentificationCode(Staff Number),AccountNo; relabel to "Qualified Teacher Status"; minor label/lookup/tag tweaks.Written by Cursor Bugbot for commit 1027673. This will update automatically on new commits. Configure here.