# Editing of data

The `resource_edit` route in Admin Portal handles both GET and POST requests for editing an existing resource of a specified type. functionality and routes:

#### Routes:

1. **GET `/resource/<string:resource_type>/<string:resource_id>/edit`**:
   * This route is used to retrieve the form for editing an existing resource.
   * It takes two parameters:
     * `resource_type`: The type of the resource to edit.
     * `resource_id`: The ID of the resource to edit.
2. **POST `/resource/<string:resource_type>/<string:resource_id>/edit`**:
   * This route is used to submit the form with updated resource attributes.
   * It also takes `resource_type` and `resource_id` parameters.

#### Functionality:

1. **Retrieve Resource for Editing**:
   * Fetches the resource object from the database based on the provided `resource_type` and `resource_id`.
2. **Handle Form Submission**:
   * If the request method is GET, renders the edit form template with pre-filled data.
   * If the request method is POST, processes the form data submitted by the user.
3. **Update Resource Attributes**:
   * Updates the attributes of the resource object based on the form data submitted.
   * Validates and converts attribute values if necessary.
4. **Additional Logic for Specific Resource Types**:
   * Contains additional logic for handling specific resource types. For example, for "mandi-receipt" resources, it checks for duplicate entries and performs related actions.
5. **Commit Changes to Database**:
   * Adds the updated resource object to the session and commits the changes to the database.
6. **Handle Resource Revisions**:
   * Calls a function `handle_resource_revision` to manage revisions of the resource.
7. **Call After Update Hook**:
   * If the resource class has an `after_update_callback` attribute, it calls the associated function, passing the updated and old resource objects.
8. **Redirect**:
   * After successful editing, redirects the user to the resource list page.
   * If the resource does not exist, redirects the user to the resource list page.
9. Editable fields include:&#x20;
   1. Receipt Number
   2. Booklet Number
   3. Mandi
   4. Crop
   5. Rate
   6. Quantity
   7. Status\
      ![](https://3898150257-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FrjNYs8KmxBlZvBKyEb2T%2Fuploads%2F1sjXRNWdUgRtmofWJB4z%2Fimage.png?alt=media\&token=609e63de-78a6-483a-8ee3-9db26498e84b)

### When a receipt is edited, the following data updates happen

**I. Sale Receipt version is created**\
Before updating the sale receipt data, a copy of the current receipt values are created and stored as a version of the receipt. This is stored in `sale_receipt_edits` table. This is used by admins or validators to monitor the number of changes done to a receipt and also have a historical context about the receipt data.\
\
All the previous versions of a sale receipt are also visible and accessible from the Admin Portal.

<div align="left" data-full-width="false"><figure><img src="https://3898150257-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FrjNYs8KmxBlZvBKyEb2T%2Fuploads%2FdAZzK5bj7A25b5AAm72b%2Fimage.png?alt=media&#x26;token=73e87051-b938-4b84-b9ce-e022446adce5" alt=""><figcaption><p>Edit History Model</p></figcaption></figure></div>

**II. Sale Receipt data is updated**\
All the modified values as done by user in the edit form are updated in the database.\ <br>

**III. Cached metrics are updated**

A force update action happens to cached metrics when a sale receipt is edited unless it is a rejected application before and after the update.

## In the /edit endpoint, update event hooks are called as follows:

```python
# Call after update hook
if hasattr(resource_class, "after_update_callback"):
    resource_class.after_update_callback(resource, old_resource)
```

This code snippet checks if the `resource_class` has an attribute named `after_update_callback`. If it does, it invokes the `after_update_callback` method, passing the `resource` (updated resource) and `old_resource` (previous version of the resource) as arguments.<br>

* The `after_update_callback` function is an after update callback for the `SalesReceiptAdmin` class. It gets triggered automatically after a sale receipt is updated. what happens in this callback:
  1. **Update User Rewards Wallet**: The function `update_user_rewards_wallet` is called to update the rewards wallet of the user associated with the sale receipt. This could involve adjusting the user's balance or rewards based on the changes made to the sale receipt.
  2. **Update Mandi Data**: The function `force_update_mandi_data` is called twice, once for the current sale receipt mandi and once for the old sale receipt mandi. This updates the mandi data, likely recalculating metrics or aggregations based on the sale receipt changes.
  3. **Update Trader Crop Data**: Functions like `update_trader_crop_data`, `update_trader_parent_crop_data`, `update_trader_crop_mandi_data`, and `update_trader_crop_mandi_info_data` are called to update various data related to the trader's crops and mandis. These updates could involve recalculating aggregated statistics or updating related information.
  4. **Update Mandi Crop Data**: Similar to updating trader data, mandi crop data is updated using the `force_update_mandi_crop_data` function. This ensures that changes in sale receipts are reflected in mandi crop metrics and aggregations.
  5. **Trigger Event Sale Receipt Update**: Finally, an event is triggered to signal that the sale receipt has been approved or rejected for first contribution . This could be used to notify user via whatsapp.