Skip to main content
Version: 1.2.1

Features

This document describes optional features and configuration options available in the Teydex KYC system.

Chunking​

Chunking is an optional feature that allows large files to be uploaded in smaller pieces, improving reliability and user experience for uploads over unstable connections.

When to Use Chunking​

  • Large file uploads (typically > 5MB)
  • Unstable network connections
  • Mobile environments with bandwidth constraints
  • Environments requiring upload resume capability

Configuration​

Chunking can be enabled through configuration settings. When enabled, the system will automatically handle file uploads in chunks rather than as single large requests.

How It Works​

The chunking process follows a specific API sequence:

  1. Initialize Upload: Call POST /transaction/upload-chunk-init/ to prepare the server for chunked upload
  2. Upload Chunks: Call POST /transaction/upload-chunk/ repeatedly for each file chunk
  3. Check Status: Use GET /transaction/upload-chunk-status/ to verify chunk upload progress
  4. Finalize Upload: Call POST /transaction/upload-chunk-finalize/ to complete the upload and reassemble the file

API Endpoints​

1. Initialize Chunked Upload​

Endpoint: POST /transaction/upload-chunk-init/ Purpose: Prepares the server for receiving file chunks and returns upload session details.

Request Body​

{
  "filename": "document.jpg",
  "file_size": 2048576,
  "chunk_size": 1024,
  "total_chunks": 2000
}

Response Body​

{
  "upload_id": "abc123-def456-ghi789",
  "chunk_size": 1024,
  "expires_at": "2024-01-15T10:30:00Z"
}

2. Upload File Chunk​

Endpoint: POST /transaction/upload-chunk/ Purpose: Uploads individual file chunks with metadata.

Request Body (multipart/form-data)​

upload_id: abc123-def456-ghi789
chunk_number: 1
chunk_data: [binary data]
chunk_hash: sha256_hash_of_chunk

Response Body​

{
  "upload_id": "abc123-def456-ghi789",
  "chunk_number": 1,
  "status": "received",
  "next_chunk": 2
}

3. Check Upload Status​

Endpoint: GET /transaction/upload-chunk-status/ Purpose: Returns the current status of chunked upload progress.

Query Parameters​

  • upload_id: The upload session ID

Response Body​

{
  "upload_id": "abc123-def456-ghi789",
  "total_chunks": 2000,
  "uploaded_chunks": 1500,
  "missing_chunks": [1501, 1502, 1505],
  "status": "in_progress"
}

4. Finalize Upload​

Endpoint: POST /transaction/upload-chunk-finalize/ Purpose: Completes the upload process and assembles chunks into the final file.

Request Body​

{
  "upload_id": "abc123-def456-ghi789",
  "file_hash": "sha256_hash_of_complete_file"
}

Response Body​

{
  "upload_id": "abc123-def456-ghi789",
  "status": "completed",
  "file_url": "/media/uploads/document.jpg",
  "file_size": 2048576
}

Benefits​

  • Reliability: Failed uploads can resume from the last successful chunk
  • Performance: Better handling of large files on mobile networks
  • User Experience: Progress indication for large uploads
  • Bandwidth Efficiency: Failed uploads don't require starting over

LDAP Authentication​

LDAP (Lightweight Directory Access Protocol) integration allows enterprises to use their existing directory services for user authentication and authorization in the Teydex system.

When to Use LDAP​

  • Enterprise environments with existing Active Directory or LDAP infrastructure
  • Centralized user management requirements
  • Single sign-on (SSO) integration needs
  • Organizations requiring role-based access control mapped from directory groups

How It Works​

  1. User Authentication: Users log in with their LDAP credentials
  2. Directory Search: System searches for the user in the configured LDAP directory
  3. Attribute Mapping: User attributes (name, email, etc.) are mapped from LDAP to application fields
  4. Group Authorization: LDAP groups are mapped to application roles for access control
  5. Session Creation: Local session is created with appropriate permissions

Supported Features​

  • User Authentication: Validate credentials against LDAP directory
  • Attribute Mapping: Map LDAP attributes to application user fields
  • Group-Based Authorization: Map LDAP groups to application roles
  • Flexible Configuration: Configurable search bases, filters, and bind credentials

Configuration​

LDAP authentication is configured through environment variables. For detailed configuration options and examples, see the LDAP Integration section in setup.md.

Available application roles that can be mapped from LDAP groups:

  • api_user: API User
  • read_only: Read-Only (default role)
  • administrator: Administrator
  • customer_representative: Customer Representative
  • customer_representative_manager: Customer Representative Manager

Maker Checker​

Maker Checker is a workflow mechanism that requires certain operations to be approved by an authorized approver before they are carried out. This mechanism minimizes the risk of errors and unauthorized actions by ensuring a second pair of eyes is involved in critical data changes.

When to Use Maker Checker​

  • When data needs to be created, updated, or deleted through the admin panel.
  • Business processes that require two-step approval.
  • Organizations that need to maintain a change history.
  • Security requirements where the same user should not both initiate and approve an operation.

How It Works​

  1. Request Creation: The user initiates a create, update, or delete operation.
  2. Change Record: The operation is saved to the database as a ChangeRequest; the actual model remains unchanged.
  3. Pending Approval: The ChangeRequest waits in pending status.
  4. Approver Decision: The authorized approver approves or rejects the request.
  5. Operation Execution: If approved, the actual operation is triggered; if rejected, no changes are made.

Supported Features​

  • Create Approval: Including new record creation operations in the approval workflow.
  • Update Approval: Including existing record update operations in the approval workflow.
  • Delete Approval: Including record deletion operations in the approval workflow.
  • Change Tracking: Recording which fields changed in update operations along with their old and new values.
  • Status Management: Tracking operation status with pending, approved, rejected, and failed statuses.
  • Integration: Integration with existing serializers and views through the mixin structure.
  • Enable/Disable Mode: The mechanism can be enabled or disabled per environment via the MAKER_CHECKER_ENABLED setting.
  • Action Independence: Other functions beyond CRUD operations can be triggered conditionally based on approval.

Integration​

1. Service Function​

Service functions containing the business logic to be executed upon approval are defined. These functions are only triggered when approval is received.

# myapp/services.py

class MyModelService:
    @staticmethod
    def create(**kwargs) -> MyModel:
        return MyModel.objects.create(**kwargs)

    @staticmethod
    def update(instance_id: str, **kwargs) -> MyModel:
        instance = MyModel.objects.get(pk=instance_id)
        for key, value in kwargs.items():
            setattr(instance, key, value)
        instance.save()
        return instance

    @staticmethod
    def delete(instance_id: str, **kwargs) -> None:
        MyModel.objects.filter(pk=instance_id).delete()

2. Serializer​

ChangeRequestSerializerMixin is added to include the create, update, and destroy methods in the approval workflow.

If there is a customized process, using SerializerMixin is not recommended.

# myapp/serializers.py
from maker_checker.mixins import ChangeRequestSerializerMixin
from .services import MyModelService

class MyModelSerializer(ChangeRequestSerializerMixin, serializers.ModelSerializer):
    change_request_action_create = MyModelService.create
    change_request_action_update = MyModelService.update

    class Meta:
        model  = MyModel
        fields = [...]


class MyModelDeleteSerializer(ChangeRequestSerializerMixin, serializers.Serializer):
    change_request_action_delete = MyModelService.delete

3. View​

ChangeRequestCreateViewMixin, ChangeRequestUpdateViewMixin, or ChangeRequestDeleteViewMixin are added to include the required methods in the approval workflow.

# myapp/views.py
from maker_checker.mixins import ChangeRequestCreateViewMixin, ChangeRequestUpdateViewMixin, ChangeRequestDeleteViewMixin

class MyModelViewSet(ChangeRequestCreateViewMixin, ChangeRequestUpdateViewMixin, ChangeRequestDeleteViewMixin, viewsets.ModelViewSet):
    serializer_class = MyModelSerializer
    queryset         = MyModel.objects.all()

4. Configuration​

# settings.py
MAKER_CHECKER_ENABLED = True  # If set to False, the approval workflow is disabled. Defaults to False.

API​

ChangeRequest List​

GET /change-requests/

ChangeRequest Detail​

GET /change-requests/{id}/

Approve / Reject​

POST /change-requests/{id}/resolve/

Request body:

FieldTypeRequiredDescription
actionstringYesapproved or rejected
notestringNoApprover note

Example:

{ "action": "approved" }
{ "action": "rejected", "note": "Missing information." }

ChangeRequest Statuses​

StatusDescription
pendingOperation is awaiting approval
approvedOperation was approved and executed
rejectedOperation was rejected
failedOperation was approved but could not be executed