Conversation
Fixes #17 Implements a backward-compatible fix for the editcarinfo.php endpoint. The script now accepts either ID or �ssetID as the identifier for updates, prioritizing ID. This resolves the contract mismatch where the Flutter client was sending �ssetID while the backend expected the primary key ID. The endpoint now also uses prepared statements and returns a standardized JSON response.
Fixes #28 Refactors getallclients.php and getallpolicies.php to use the standard API response envelope: { success, message, data: { items: [...] } }. Also updates getallpolicies.php to use the JWT-based auth check instead of the legacy phpPassword.
Reviewer's GuideStandardizes backend API response envelopes for car info, policies, and clients endpoints, introduces JWT-based protection for policies/clients, improves editcarinfo update logic, and adds community standards/docs plus CI Java version bump. Sequence diagram for JWT-protected policies/clients retrieval with standardized response envelopesequenceDiagram
actor Client
participant Backend as Backend_PHP
participant Auth as Auth_check_PHP
participant DB as MySQL_DB
Client->>Backend: HTTP GET /backend/clients/getallclients.php<br/>Authorization: Bearer token
Backend->>Auth: require_once auth_check.php
Auth->>Auth: Validate_JWT(token)
alt JWT_valid
Auth-->>Backend: currentUserId
Backend->>DB: SELECT * FROM clients ORDER BY clientname ASC
alt Query_success
DB-->>Backend: Result_set(rows)
Backend->>Backend: Build_response(success=true,<br/>message=Clients_retrieved_successfully,<br/>data.items=rows)
Backend-->>Client: 200 OK<br/>{ success, message, data }
else Query_failure
DB-->>Backend: Error
Backend->>Backend: Throw Exception
Backend->>Client: 500 Internal_Server_Error<br/>{ success=false, message, data=null }
end
else JWT_invalid
Auth-->>Backend: Authentication_error
Backend-->>Client: 401 Unauthorized<br/>{ success=false, message, data=null }
end
Note over Client,Backend: getallpolicies.php follows the same pattern<br/>but uses a JOIN query and wraps results in data.items and data.count
File-Level Changes
Possibly linked issues
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| $response["success"] = true; | ||
| $response["clients"] = $clients; | ||
| $response["message"] = "Clients retrieved successfully."; | ||
| $response["data"] = ["items" => $clients]; |
There was a problem hiding this comment.
This endpoint now nests the list under data.items, but the Flutter clients still read a top‑level clients array (e.g., lib/client/pages/clientlist.dart expects jsonData['clients'] or a direct list). Because data is now an object instead of a list, those callers fall into the error path and show “Müşteri verisi bulunamadı”, even though the API succeeded. Consider keeping the legacy clients key or updating all client call sites to read data.items.
Useful? React with 👍 / 👎.
| $response["success"] = true; | ||
| $response["message"] = "Policies retrieved successfully."; | ||
| $response["data"] = ["items" => $policies, "count" => count($policies)]; |
There was a problem hiding this comment.
The response now moves the policies list into data.items, but multiple Flutter screens still parse policies at the top level (e.g., lib/police/pages/all_policies.dart uses policiesJson['policies']). With the new shape, those screens will render zero policies even on success. Either preserve policies for backward compatibility or update all policy consumers to read data.items.
Useful? React with 👍 / 👎.
| // Secure this endpoint using JWT authentication | ||
| require_once __DIR__ . '/../auth/auth_check.php'; |
There was a problem hiding this comment.
Switching this endpoint to auth_check.php makes the Authorization header mandatory, and auth_check.php immediately returns 401 when it’s missing. The Flutter app still calls this endpoint with only phpPassword in the body (e.g., lib/police/pages/all_policies.dart), so those calls will now fail. If the mobile app isn’t updated to send JWTs everywhere, you’ll need a temporary compatibility path.
Useful? React with 👍 / 👎.
Adds composer.json to define PHP dependencies (phpunit, phinx). Updates phpunit.xml.dist and adds a bootstrap file to correctly load test files and functions. This resolves the 'composer.json not found' error in the Backend CI job.
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 4 issues, and left some high level feedback:
- In the new standardized response envelopes, consider avoiding exposing raw database or internal exception messages (e.g.,
mysqli_errortext) directly inmessageto prevent leaking internal details to API consumers; instead log the detailed error and return a generic user-facing message. - The response
datapayload shape differs between endpoints (e.g.,getallpoliciesreturns{"items": [...], "count": n}whilegetallclientsreturns only{"items": [...]}); aligning these structures will make client-side handling simpler and more predictable.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- In the new standardized response envelopes, consider avoiding exposing raw database or internal exception messages (e.g., `mysqli_error` text) directly in `message` to prevent leaking internal details to API consumers; instead log the detailed error and return a generic user-facing message.
- The response `data` payload shape differs between endpoints (e.g., `getallpolicies` returns `{"items": [...], "count": n}` while `getallclients` returns only `{"items": [...]}`); aligning these structures will make client-side handling simpler and more predictable.
## Individual Comments
### Comment 1
<location> `backend/carinfos/editcarinfo.php:62-64` </location>
<code_context>
- $sql = "UPDATE carinfos SET ".implode(', ',$set)." WHERE ID = ?";
- $types.='i';
- $vals[] = $id;
+ if (empty($setClauses)) {
+ throw new Exception('No fields to update were provided.');
+ }
+
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Returning a 500 for missing update fields makes a client-side error look like a server error.
Because no HTTP status is set before throwing, the catch block will see `http_response_code() === 200` and turn this into a 500, misclassifying a client error as a server error. Consider explicitly setting an appropriate 4xx status (e.g., 400 or 422) before throwing so it’s consistent with other validation failures like the missing ID/assetID case.
```suggestion
if (empty($setClauses)) {
// Client-side validation error: no fields provided to update
http_response_code(400);
throw new Exception('No fields to update were provided.');
}
```
</issue_to_address>
### Comment 2
<location> `backend/carinfos/editcarinfo.php:72-80` </location>
<code_context>
+ $sql = "UPDATE carinfos SET " . implode(', ', $setClauses) . " WHERE $whereField = ?";
+
$stmt = $connNow->prepare($sql);
- if(!$stmt) throw new Exception('Prepare hatası: '.$connNow->error);
+ if (!$stmt) {
+ throw new Exception('SQL statement preparation failed: ' . $connNow->error);
+ }
- $stmt->bind_param($types, ...$vals);
- if(!$stmt->execute()) throw new Exception('Execute hatası: '.$stmt->error);
+ $stmt->bind_param($bindTypes, ...$bindValues);
+
+ if (!$stmt->execute()) {
+ throw new Exception('SQL statement execution failed: ' . $stmt->error);
+ }
</code_context>
<issue_to_address>
**🚨 issue (security):** Including raw SQL error messages in the JSON response leaks internal database details.
Both the prepare and execute branches include `$connNow->error` / `$stmt->error` in exceptions that are sent to the client, potentially exposing schema and internal DB details. Log the full DB error server-side and return a generic message (optionally with a stable error code) to the client instead.
</issue_to_address>
### Comment 3
<location> `backend/policies/getallpolicies.php:34-36` </location>
<code_context>
- $resp['success']=false;
- $resp['message']=$e->getMessage();
+
+} catch (Exception $e) {
+ if (http_response_code() === 200) { // If no HTTP code was set by us, it's an internal error
+ http_response_code(500);
</code_context>
<issue_to_address>
**🚨 issue (security):** The error response exposes raw exception messages, including database errors, to clients.
Because query failures throw `new Exception(mysqli_error($connNow))`, the catch block ends up returning raw database errors in the JSON response, which can expose schema and SQL details. Instead, log the detailed error server-side and return a generic error message with HTTP 500 to the client.
</issue_to_address>
### Comment 4
<location> `CODE_OF_CONDUCT.md:5` </location>
<code_context>
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
</code_context>
<issue_to_address>
**issue (typo):** Adjust the phrase "pledge to making" to a grammatically correct form.
Consider revising this to a more natural construction, e.g. "pledge to make participation in our project... a harassment-free experience" or "are committed to making participation in our project... a harassment-free experience."
```suggestion
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to make participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
```
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| if (empty($setClauses)) { | ||
| throw new Exception('No fields to update were provided.'); | ||
| } |
There was a problem hiding this comment.
suggestion (bug_risk): Returning a 500 for missing update fields makes a client-side error look like a server error.
Because no HTTP status is set before throwing, the catch block will see http_response_code() === 200 and turn this into a 500, misclassifying a client error as a server error. Consider explicitly setting an appropriate 4xx status (e.g., 400 or 422) before throwing so it’s consistent with other validation failures like the missing ID/assetID case.
| if (empty($setClauses)) { | |
| throw new Exception('No fields to update were provided.'); | |
| } | |
| if (empty($setClauses)) { | |
| // Client-side validation error: no fields provided to update | |
| http_response_code(400); | |
| throw new Exception('No fields to update were provided.'); | |
| } |
| $stmt = $connNow->prepare($sql); | ||
| if(!$stmt) throw new Exception('Prepare hatası: '.$connNow->error); | ||
| if (!$stmt) { | ||
| throw new Exception('SQL statement preparation failed: ' . $connNow->error); | ||
| } | ||
|
|
||
| $stmt->bind_param($types, ...$vals); | ||
| if(!$stmt->execute()) throw new Exception('Execute hatası: '.$stmt->error); | ||
| $stmt->bind_param($bindTypes, ...$bindValues); | ||
|
|
||
| if (!$stmt->execute()) { | ||
| throw new Exception('SQL statement execution failed: ' . $stmt->error); |
There was a problem hiding this comment.
🚨 issue (security): Including raw SQL error messages in the JSON response leaks internal database details.
Both the prepare and execute branches include $connNow->error / $stmt->error in exceptions that are sent to the client, potentially exposing schema and internal DB details. Log the full DB error server-side and return a generic message (optionally with a stable error code) to the client instead.
| } catch (Exception $e) { | ||
| http_response_code(500); | ||
| $response["message"] = "An error occurred: " . $e->getMessage(); |
There was a problem hiding this comment.
🚨 issue (security): The error response exposes raw exception messages, including database errors, to clients.
Because query failures throw new Exception(mysqli_error($connNow)), the catch block ends up returning raw database errors in the JSON response, which can expose schema and SQL details. Instead, log the detailed error server-side and return a generic error message with HTTP 500 to the client.
|
|
||
| ## Our Pledge | ||
|
|
||
| In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation. |
There was a problem hiding this comment.
issue (typo): Adjust the phrase "pledge to making" to a grammatically correct form.
Consider revising this to a more natural construction, e.g. "pledge to make participation in our project... a harassment-free experience" or "are committed to making participation in our project... a harassment-free experience."
| In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation. | |
| In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to make participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation. |
There was a problem hiding this comment.
Pull request overview
This PR implements a standardized API response envelope across backend endpoints, fixes the CarInfo API to support both ID and assetID parameters, secures the policies endpoint with JWT authentication, and adds community standards documentation. The changes modernize the API contract and improve security, but introduce breaking changes that require coordinated frontend updates.
Key changes include:
- Migrated
getallpolicies.phpfrom phpPassword to JWT authentication - Standardized response format to
{"success": bool, "message": string, "data": object|null}structure - Enhanced
editcarinfo.phpto accept both ID and assetID for more flexible updates
Reviewed changes
Copilot reviewed 14 out of 14 changed files in this pull request and generated 9 comments.
Show a summary per file
| File | Description |
|---|---|
| backend/policies/getallpolicies.php | Adds JWT authentication and standardizes response envelope, changing from {"policies": [...]} to {"data": {"items": [...]}} structure |
| backend/clients/getallclients.php | Standardizes response envelope from {"clients": [...]} to {"data": {"items": [...]}} structure |
| backend/carinfos/editcarinfo.php | Fixes API contract mismatch by supporting both ID and assetID parameters; standardizes response envelope and improves error handling |
| LICENSE | Adds MIT License for the project |
| CONTRIBUTING.md | Adds contribution guidelines and code style standards |
| CODE_OF_CONDUCT.md | Adds community code of conduct |
| .github/workflows/release.yml | Updates Java version from 11 to 17 for Android builds |
| .github/PULL_REQUEST_TEMPLATE.md | Adds PR template for structured pull request descriptions |
| .github/ISSUE_TEMPLATE/feature_request.md | Adds feature request issue template |
| .github/ISSUE_TEMPLATE/bug_report.md | Adds bug report issue template |
Comments suppressed due to low confidence (1)
backend/clients/getallclients.php:29
- This API returns raw database error messages to clients by throwing
new Exception(mysqli_error($connNow))and then serializing"An error occurred: " . $e->getMessage()into the JSON response. Exposing low-level database errors gives attackers insight into your schema and environment that can be used to craft more effective attacks. You should log detailed DB errors server-side and only send a generic failure message in the HTTP response body.
throw new Exception(mysqli_error($connNow));
}
} catch (Exception $e) {
http_response_code(500);
$response["message"] = "An error occurred: " . $e->getMessage();
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| $response["message"] = "Clients retrieved successfully."; | ||
| $response["data"] = ["items" => $clients]; |
There was a problem hiding this comment.
Breaking change detected: The response structure has been changed from {"clients": [...], "success": true} to {"data": {"items": [...]}, "success": true, "message": "..."}. Multiple frontend consumers (lib/client/pages/clientlist.dart:63, lib/police/pages/newpolicy.dart:140, lib/police/pages/editpolicy.dart:138, lib/police/pages/receivables_page.dart:135) expect the clients key directly at the root level. While clientlist.dart has a fallback that checks both clients and data keys (line 63), other consumers do not have this fallback and will break. Consider either: 1) Keeping backward compatibility by including both formats temporarily, or 2) Coordinating this backend change with corresponding frontend updates in the same PR.
| $response["message"] = "Clients retrieved successfully."; | |
| $response["data"] = ["items" => $clients]; | |
| $response["message"] = "Clients retrieved successfully."; | |
| // New structured response for newer clients | |
| $response["data"] = ["items" => $clients]; | |
| // Backward-compatible root-level key for existing frontend consumers | |
| $response["clients"] = $clients; |
| if($val==='') $val=null; // boş ise null kaydet | ||
| $set[] = "$f = ?"; | ||
| $vals[] = $val; | ||
|
|
There was a problem hiding this comment.
The date format validation for the seyruseferdate field has been removed in this refactoring. The original code validated that dates matched the YYYY-MM-DD format using a regex pattern. This validation should be restored to ensure data integrity. Add validation similar to: if ($value !== '' && !preg_match('/^\d{4}-\d{2}-\d{2}$/', $value)) throw new Exception('seyruseferdate must be in YYYY-MM-DD format'); before line 55.
| // Date format validation for seyruseferdate (YYYY-MM-DD) | |
| if ($field === 'seyruseferdate' && $value !== '' && !preg_match('/^\d{4}-\d{2}-\d{2}$/', $value)) { | |
| throw new Exception('seyruseferdate must be in YYYY-MM-DD format'); | |
| } |
| } | ||
| $response["success"] = true; | ||
| $response["message"] = "Policies retrieved successfully."; | ||
| $response["data"] = ["items" => $policies, "count" => count($policies)]; |
There was a problem hiding this comment.
The response envelope structure is inconsistent across the codebase. This endpoint uses {"data": {"items": [...]}}, while similar endpoints like getcarinfo.php (backend/carinfos/getcarinfo.php:7) use {"carinfo": ...} as the data key. For true API standardization, consider documenting the standard envelope format and applying it consistently across all endpoints. The standard structure should be: {"success": bool, "message": string, "data": object|array|null} where the data key always contains the actual payload, regardless of whether it's a single item, list, or metadata object.
| $response["data"] = ["items" => $policies, "count" => count($policies)]; | |
| $response["data"] = $policies; |
| $sql = "UPDATE carinfos SET ".implode(', ',$set)." WHERE ID = ?"; | ||
| $types.='i'; | ||
| $vals[] = $id; | ||
| if (empty($setClauses)) { |
There was a problem hiding this comment.
When no fields are provided for update, the error message "No fields to update were provided." will be shown, but the HTTP status code remains 200 (OK). Consider setting an appropriate HTTP status code (e.g., 400 Bad Request) before throwing the exception, similar to how it's done for missing identifiers on lines 32-33.
| if (empty($setClauses)) { | |
| if (empty($setClauses)) { | |
| http_response_code(400); |
| // For now, we retain the phpPassword check for basic security. | ||
| if (($phpPassword ?? '') !== ($_POST['phpPassword'] ?? '')) { |
There was a problem hiding this comment.
The comment indicates JWT authentication will be added in a later phase (P2), but this endpoint is already being refactored in this PR focused on security improvements (changing authentication from phpPassword to JWT for getallpolicies.php). Consider prioritizing JWT authentication for this endpoint as well, since it handles sensitive car information updates. If that's not feasible in this PR, at least ensure the phpPassword check includes proper timing-safe comparison to prevent timing attacks.
| // For now, we retain the phpPassword check for basic security. | |
| if (($phpPassword ?? '') !== ($_POST['phpPassword'] ?? '')) { | |
| // For now, we retain the phpPassword check for basic security using timing-safe comparison. | |
| $providedPhpPassword = isset($_POST['phpPassword']) ? (string) $_POST['phpPassword'] : ''; | |
| $expectedPhpPassword = (string) ($phpPassword ?? ''); | |
| if ($providedPhpPassword === '' || !hash_equals($expectedPhpPassword, $providedPhpPassword)) { |
| $resp['message']='Araç güncellendi'; | ||
| $resp['affected']=$stmt->affected_rows; | ||
| $response['success'] = true; | ||
| $response['message'] = 'Car info updated successfully.'; |
There was a problem hiding this comment.
The error message strings have been changed from Turkish to English (e.g., "Araç güncellendi" → "Car info updated successfully."), but other parts of the codebase still use Turkish error messages (e.g., backend/carinfos/getcarinfo.php uses Turkish: "Invalid authentication."). This creates inconsistency in the user experience. Consider either: 1) Maintaining Turkish messages to match the rest of the codebase, or 2) Implementing proper internationalization (i18n) support if multilingual messages are desired.
| $response["success"] = true; | ||
| $response["message"] = "Policies retrieved successfully."; | ||
| $response["data"] = ["items" => $policies, "count" => count($policies)]; |
There was a problem hiding this comment.
Breaking change detected: The response structure has been changed from {"policies": [...], "success": true, "count": N} to {"data": {"items": [...], "count": N}, "success": true, "message": "..."}. Multiple frontend consumers (lib/police/pages/all_policies.dart:136, lib/main.dart:159, lib/police/pages/receivables_page.dart:132) expect the policies key directly at the root level and will break with this change. While some files have fallback logic (e.g., remainings_page.dart:77), not all do. Consider either: 1) Keeping backward compatibility by including both formats temporarily, or 2) Coordinating this backend change with corresponding frontend updates in the same PR.
| $response["success"] = true; | |
| $response["message"] = "Policies retrieved successfully."; | |
| $response["data"] = ["items" => $policies, "count" => count($policies)]; | |
| $policyCount = count($policies); | |
| $response["success"] = true; | |
| $response["message"] = "Policies retrieved successfully."; | |
| // New structure for updated clients | |
| $response["data"] = ["items" => $policies, "count" => $policyCount]; | |
| // Backward-compatible fields for existing clients | |
| $response["policies"] = $policies; | |
| $response["count"] = $policyCount; |
| throw new Exception(mysqli_error($connNow)); | ||
| } | ||
|
|
||
| $policies = array(); | ||
| while($row = mysqli_fetch_assoc($result)) { | ||
| $policies[] = $row; | ||
| } | ||
|
|
||
| echo json_encode(array("policies" => $policies, "success" => true, "count" => count($policies))); | ||
| }else{ | ||
| die(json_encode(array("success" => false, "message" => "Invalid PHP password."))); | ||
|
|
||
| } catch (Exception $e) { | ||
| http_response_code(500); | ||
| $response["message"] = "An error occurred: " . $e->getMessage(); |
There was a problem hiding this comment.
This endpoint exposes raw database error messages to API clients by throwing new Exception(mysqli_error($connNow)) and then returning "An error occurred: " . $e->getMessage() in the JSON response. An attacker who can trigger a database error (e.g., via operational failures or future query changes) can harvest internal details about your schema or infrastructure, which materially aids further exploitation. Instead, log detailed database errors on the server and return only a generic, client-safe error message in the HTTP response.
| $stmt = $connNow->prepare($sql); | ||
| if(!$stmt) throw new Exception('Prepare hatası: '.$connNow->error); | ||
| if (!$stmt) { | ||
| throw new Exception('SQL statement preparation failed: ' . $connNow->error); | ||
| } | ||
|
|
||
| $stmt->bind_param($types, ...$vals); | ||
| if(!$stmt->execute()) throw new Exception('Execute hatası: '.$stmt->error); | ||
| $stmt->bind_param($bindTypes, ...$bindValues); | ||
|
|
||
| if (!$stmt->execute()) { | ||
| throw new Exception('SQL statement execution failed: ' . $stmt->error); | ||
| } | ||
|
|
||
| $resp['success']=true; | ||
| $resp['message']='Araç güncellendi'; | ||
| $resp['affected']=$stmt->affected_rows; | ||
| $response['success'] = true; | ||
| $response['message'] = 'Car info updated successfully.'; | ||
| $response['data'] = ['affected_rows' => $stmt->affected_rows]; | ||
|
|
||
| $stmt->close(); | ||
| } catch(Exception $e){ | ||
| $resp['success']=false; | ||
| $resp['message']=$e->getMessage(); | ||
|
|
||
| } catch (Exception $e) { | ||
| if (http_response_code() === 200) { // If no HTTP code was set by us, it's an internal error | ||
| http_response_code(500); | ||
| } | ||
| $response['success'] = false; | ||
| $response['message'] = $e->getMessage(); |
There was a problem hiding this comment.
This endpoint leaks internal database error details to callers by constructing exceptions with ... $connNow->error / $stmt->error and then returning $e->getMessage() directly in the JSON message field. An attacker who can trigger SQL preparation or execution failures can obtain detailed information about the database schema or environment, which can significantly aid further exploitation. Instead, capture and log the detailed exception messages server-side and return a generic, user-friendly error message in the API response.
Summary by Sourcery
Standardize backend API responses and update project community and workflow configuration.
New Features:
Bug Fixes:
Enhancements:
Build:
Documentation: