Conversation
876a2b7 to
7ea6b21
Compare
c313d2f to
5a96b69
Compare
|
Review app for PR 4360 was deleted |
5a96b69 to
bfe422a
Compare
bfe422a to
d6be1a0
Compare
aa45e7c to
c9587ea
Compare
| if @flagged_fe_providers_form.save | ||
| flash[:notice] = "Flagged providers CSV uploaded successfully." | ||
| else | ||
| flash[:alert] = @flagged_fe_providers_form.errors.full_messages |
There was a problem hiding this comment.
probably need join(", ") on the end as think this returns an array
| :reason, | ||
| inclusion: { | ||
| in: -> { reasons.keys }, | ||
| messsage: "reason must be one of #{reasons.keys}" |
There was a problem hiding this comment.
same thing and probably want join(", ") on the end
| def flags | ||
| @flags ||= csv.map do |row| | ||
| Policies::FurtherEducationPayments::ProviderFlag.new( | ||
| academic_year: AcademicYear.current, |
There was a problem hiding this comment.
i think i would have preferred academic year to be present on claimant flagging and not for provider flagging. for claimant flagging it might be useful for keeping them around for future years for future claims
here though as you can't specify academic year and is based on time of upload it means it will only apply for this year. which means it will not persist thru to following years. it will then get deleted on a new upload. is this by design or happy accident. I'm thinking options are:
- leave as is
- add year to csv
- get rid of year concept entirely and becomes perpetual
There was a problem hiding this comment.
Yeah I think I'll change this to take the approach used in the claimant flagging, where we create the task in the claim verifiers and write the attributes from the flag to the task, that way when flags are nuked we still have a record of them (think deleting and recreating flags on each csv upload is the way to go)
There was a problem hiding this comment.
Have added two commits
use claim verifier to create the task - that way if we remove a provider's ukprn from the csv we wont lose the fact that a claim was flagged. Only would be an issue for claims where the task wasn't passed. On a general note I think we should move to only creating tasks in claim verifiers so they're always persisted.
remove academic year - agree makes sense to keep these around as the AY isn't specified in the CSV.
7813d6a to
32173f3
Compare
One provider had a large number of claims clawed back last year due to inaccurate provider verification. We want to support admins being able to upload a CSV of urns such that any FE claims where the provider's urn is in this list are flagged with an additional task. Exact instructions for this task are still TBD. The CSV also has an extra "reason" column to determine the reason claims from this provider are flagged. Currently we only support clawback. If we want to support other reasons in future we should add a claim verifier which persists the task and store the reason for flagging provider in the task's meta data, that way when we delete the flags we don't lose the reason for the claim being flagged.
Due to the fact that most tasks aren't persisted until they're completed we have to create a `ClaimCheckingTasks` in the claim. We can probably clean up some creations of `ClaimCheckingTasks` and just reference `Claim#claim_checking_tasks` in future.
Change to using a claim verifier to create the task, that way we persist the flag information if the provider flagging csv is updated to remove the fe provider's ukprn
The csv doesn't require an academic on provider flags so it's more intuitive for them to be perpetual until the provider's ukprn is removed from the csv.
32173f3 to
5f442c4
Compare
Adds provider flagging mechanism.
Requirement for policy is to flag all claims from a certain provider for
additional scrutiny.
We've implement this as a CSV upload containing URNs (we don't expect their to
be many). If a claim is submitted for an FE provider who's urn is in the list
we'll create an additional task to review the provider verification details.
The first commit in this PR also implements a mechanism to for tasks to block
approval until they've been completed, we just add the task name to
Task::BLOCKS_APPROVAL. There's some trickiness here as, most, tasks aren'tpersisted until they're completed, so we have to construct task objects for
these incomplete tasks.
Worth reviewing these commits separately.
flagging.mp4