update vclaim sedikit - #370
Merged
Merged
Conversation
|
@adlylee is attempting to deploy a commit to the basoro's projects Team on Vercel. A member of the Team first needs to authorize it. |
Contributor
Reviewer's GuideAdds SEP update support, refines rujukan keluar (referral out) handling and display, introduces PRB metadata on control plans, tweaks several VClaim views/JS behaviors, relaxes HTML escaping in Vedika index, and adds a minor debug comment in Farmasi. Sequence diagram for new SEP insert vs update flow in postSaveSEPsequenceDiagram
actor User
participant Browser
participant VclaimAdmin as Vclaim_Admin
participant BpjsService
participant BPJS_API
User->>Browser: Submit SEP form
Browser->>VclaimAdmin: POST postSaveSEP(no_sep, form_fields)
alt [no_sep is empty]
VclaimAdmin->>VclaimAdmin: Build insert SEP payload (noKartu, tglSep, rujukan, jaminan, ...)
VclaimAdmin->>VclaimAdmin: Set url = api_url + SEP/2.0/insert
VclaimAdmin->>BpjsService: post(url, data, consid, secretkey, user_key, tStamp)
else [no_sep is present]
VclaimAdmin->>VclaimAdmin: Build update SEP payload (noSep, klsRawat, jaminan, ...)
VclaimAdmin->>VclaimAdmin: Set url = api_url + SEP/2.0/update
VclaimAdmin->>BpjsService: put(url, data, consid, secretkey, user_key, tStamp)
end
BpjsService->>BPJS_API: HTTP request (POST or PUT)
BPJS_API-->>BpjsService: JSON response
BpjsService-->>VclaimAdmin: $output
VclaimAdmin->>VclaimAdmin: json_decode($output)
VclaimAdmin-->>Browser: Result message / redirect
Browser-->>User: Show SEP save/update result
Sequence diagram for new rujuk keluar delete flowsequenceDiagram
actor User
participant Browser
participant VclaimAdmin as Vclaim_Admin
participant BpjsService
participant BPJS_API
participant DB as Database
User->>Browser: Click delete rujukan (hapus_rujuk)
Browser->>VclaimAdmin: POST postDeleteRujukKeluar(no_sep, no_rujukan)
VclaimAdmin->>VclaimAdmin: Build request[t_rujukan](noRujukan, user)
VclaimAdmin->>VclaimAdmin: json_encode(data)
VclaimAdmin->>VclaimAdmin: postDeleteRujukan(data, isReturn = true)
VclaimAdmin->>BpjsService: delete(api_url + Rujukan/delete, data, consid, secretkey, user_key, tStamp)
BpjsService->>BPJS_API: HTTP DELETE
BPJS_API-->>BpjsService: JSON response
BpjsService-->>VclaimAdmin: $output
VclaimAdmin->>VclaimAdmin: json_decode($output) as json
VclaimAdmin-->>VclaimAdmin: return json to postDeleteRujukKeluar
alt [json.metaData.code == 200]
VclaimAdmin->>DB: delete from bridging_rujukan_bpjs where no_sep, no_rujukan
VclaimAdmin-->>Browser: "Data Rujukan telah dihapus!!"
else
VclaimAdmin->>DB: delete from bridging_rujukan_bpjs where no_sep, no_rujukan
VclaimAdmin-->>Browser: metaData.message (HTML-escaped)
end
Browser-->>User: Show deletion result and refresh rujukkeluardisplay
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Hey - I've found 2 issues, and left some high level feedback:
- In
postDeleteRujukKeluar, theuserfield is hardcoded to "Coba Ws"; consider wiring this to the actual authenticated/SEP user (similar to other SEP calls) so auditing and API semantics stay consistent. - The new
postDeleteRujukKeluardeletes thebridging_rujukan_bpjsrow even when the BPJS API returns an error, which could leave local data out of sync with BPJS; you may want to only delete locally on success or clearly handle the desync case.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- In `postDeleteRujukKeluar`, the `user` field is hardcoded to "Coba Ws"; consider wiring this to the actual authenticated/SEP user (similar to other SEP calls) so auditing and API semantics stay consistent.
- The new `postDeleteRujukKeluar` deletes the `bridging_rujukan_bpjs` row even when the BPJS API returns an error, which could leave local data out of sync with BPJS; you may want to only delete locally on success or clearly handle the desync case.
## Individual Comments
### Comment 1
<location path="plugins/vclaim/Admin.php" line_range="2019-2022" />
<code_context>
}
- public function postDeleteRujukan($data = [])
+ public function postDeleteRujukan($data = [],$isReturn = true)
{
date_default_timezone_set('UTC');
</code_context>
<issue_to_address>
**question (bug_risk):** Introducing `$isReturn` changes the behavior of existing callers of `postDeleteRujukan`.
With `$isReturn` defaulting to `true`, existing callers will now return `$json` instead of executing the decryption/echo/exit block. Previously this method always wrote the response and terminated. Any routes expecting that side-effect may now just return an array and continue execution. Consider defaulting `$isReturn` to `false` and only enabling the new behavior from `postDeleteRujukKeluar()`, or ensure all existing call sites are updated for the new contract.
</issue_to_address>
### Comment 2
<location path="plugins/vclaim/Admin.php" line_range="3316-3318" />
<code_context>
+ $no_rujukan = $_POST['no_rujukan'];
+ $data = [
+ 'request' => [
+ "t_rujukan" => [
+ "noRujukan" => $no_rujukan,
+ "user" => "Coba Ws"
+ ]
+ ]
</code_context>
<issue_to_address>
**suggestion:** Hard-coded BPJS `user` value in delete-rujukan request reduces traceability.
The delete payload sets `"user" => "Coba Ws"` instead of using the authenticated user (or the existing `sep_user`-style value). This breaks consistency with other BPJS calls and reduces auditability. Please pass the actual operator identity here, or at least source the value from a shared configuration rather than hard-coding it.
Suggested implementation:
```
public function postDeleteRujukKeluar()
{
$no_sep = $_POST['no_sep'];
$no_rujukan = $_POST['no_rujukan'];
// Prefer configured BPJS user; fall back to authenticated operator username
$bpjsUser = $this->config->item('bpjs_user');
if (empty($bpjsUser) && $this->session && $this->session->userdata('username')) {
$bpjsUser = $this->session->userdata('username');
}
$data = [
'request' => [
't_rujukan' => [
'noRujukan' => $no_rujukan,
'user' => $bpjsUser,
],
],
];
```
1. Ensure that the CodeIgniter config item `bpjs_user` is defined (e.g. in `application/config/config.php` or a BPJS-specific config file) and, if needed, aligned with the existing `sep_user`/BPJS user configuration pattern used elsewhere in `plugins/vclaim/Admin.php`.
2. Confirm that the session library is loaded and that `username` (or whichever field represents the operator identity) is the correct key; if your app uses a different field (e.g. `user_id`, `nama_user`, or `sep_user`), update the `userdata(...)` call accordingly.
3. For full consistency with other BPJS calls, you may want to refactor the logic that determines `$bpjsUser` into a shared helper or class property (e.g. `$this->getBpjsUser()` or `$this->sep_user`) and reuse it across all VClaim request builders.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Comment on lines
+2019
to
2022
| public function postDeleteRujukan($data = [],$isReturn = true) | ||
| { | ||
| date_default_timezone_set('UTC'); | ||
| $tStamp = strval(time() - strtotime("1970-01-01 00:00:00")); |
Contributor
There was a problem hiding this comment.
question (bug_risk): Introducing $isReturn changes the behavior of existing callers of postDeleteRujukan.
With $isReturn defaulting to true, existing callers will now return $json instead of executing the decryption/echo/exit block. Previously this method always wrote the response and terminated. Any routes expecting that side-effect may now just return an array and continue execution. Consider defaulting $isReturn to false and only enabling the new behavior from postDeleteRujukKeluar(), or ensure all existing call sites are updated for the new contract.
Comment on lines
+3316
to
+3318
| "t_rujukan" => [ | ||
| "noRujukan" => $no_rujukan, | ||
| "user" => "Coba Ws" |
Contributor
There was a problem hiding this comment.
suggestion: Hard-coded BPJS user value in delete-rujukan request reduces traceability.
The delete payload sets "user" => "Coba Ws" instead of using the authenticated user (or the existing sep_user-style value). This breaks consistency with other BPJS calls and reduces auditability. Please pass the actual operator identity here, or at least source the value from a shared configuration rather than hard-coding it.
Suggested implementation:
public function postDeleteRujukKeluar()
{
$no_sep = $_POST['no_sep'];
$no_rujukan = $_POST['no_rujukan'];
// Prefer configured BPJS user; fall back to authenticated operator username
$bpjsUser = $this->config->item('bpjs_user');
if (empty($bpjsUser) && $this->session && $this->session->userdata('username')) {
$bpjsUser = $this->session->userdata('username');
}
$data = [
'request' => [
't_rujukan' => [
'noRujukan' => $no_rujukan,
'user' => $bpjsUser,
],
],
];
- Ensure that the CodeIgniter config item
bpjs_useris defined (e.g. inapplication/config/config.phpor a BPJS-specific config file) and, if needed, aligned with the existingsep_user/BPJS user configuration pattern used elsewhere inplugins/vclaim/Admin.php. - Confirm that the session library is loaded and that
username(or whichever field represents the operator identity) is the correct key; if your app uses a different field (e.g.user_id,nama_user, orsep_user), update theuserdata(...)call accordingly. - For full consistency with other BPJS calls, you may want to refactor the logic that determines
$bpjsUserinto a shared helper or class property (e.g.$this->getBpjsUser()or$this->sep_user) and reuse it across all VClaim request builders.
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 free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Summary by Sourcery
Support both creation and update of SEP records with corresponding VClaim API calls, enhance PRB-related control features, and refine referral (rujukan) management and display across VClaim views, while adjusting Vedika rendering and exposing an additional Farmasi JS endpoint.
New Features:
Bug Fixes:
Enhancements: