Third Party Monitoring Module
  • Third Party Monitoring Module Documentation
  • INTRODUCTION
    • Glossary / Terminology
    • FAQ
    • Releases / Changelog*
    • Report an Issue / Contact us
  • PRODUCT / END-USER DOCUMENTATION
    • Overview
      • User rights and permissions
    • Third Party Monitoring Module Navigation
    • Overall User Interface
    • Third Party Monitors section
      • List of Third Party Monitors
      • TPM partner details screen
    • List of Visits section
      • List of Visits
      • Visit details
      • Statuses and corresponding actions
        • Draft
        • Assigned
        • TPM Accepted
        • TPM Rejected
        • Cancelled
        • TPM Reported
        • Sent Back to TPM
        • UNICEF Approved
      • Emails notifications flow
    • TPM workflow
  • TECHNICAL DOCUMENTATION
    • Architecture
    • Development Setup
    • Deployment / DevOps
    • Backend Module structure
    • Data Model
    • Fixtures & management commands
    • API Documentation
      • Error Handling
    • Synchronization with VISION
    • Permissions framework
    • FSM Transitions conditions
    • FSM Transitions in view
    • API Metadata
    • Serializer Mixins
    • Model Mixins
    • Tests
    • Attachments
    • Email links & Tokens Authorization
    • Frontend
      • Module structure
      • Build process
      • Tests
Powered by GitBook
On this page
  1. TECHNICAL DOCUMENTATION

API Metadata

PreviousFSM Transitions in viewNextSerializer Mixins

Last updated 6 years ago

As far as we use dynamic list of fields in every specific case, we've reworked existing rest framework metadata mechanism (OPTIONS requests). By default only editable fields are shown here, so for clear understanding of current situation, viewable fields were added inside GET action (unicef_restlib.metadata.CRUActionsMetadataMixin). When fields lists are prepared, they can be filtered using permissions with etools.applications.utils.permissions.metadata.PermissionsBasedMetadataMixin. Also, transitions set can vary depending on the permissions, so they also should be available in the metadata. etools.applications.permissions2.PermittedFSMTransitionActionMetadataMixin was designed to do this. Additionally, transitions can be renamed on the fly using name in custom attribute of transition. For example:

custom={ 'name': _('Cancel Visit') }

or lambda function

custom={    
    'name': lambda obj: _('Re-assign') if obj.status == TPMVisit.STATUSES.tpm_rejected else _('Assign')
}

If none is provided, function name will be used as the display name in the metadata.

So here is an example of the metadata class that can correctly communicate with permissions and correctly display information about the availability of each field.

class ExampleMetadata(
    CRUActionsMetadataMixin,
    PermissionsBasedMetadataMixin,
    PermittedFSMTransitionActionMetadataMixin,
    SimpleMetadata
):
    def get_serializer_info(self, serializer):
        if serializer.instance:
            serializer.context['instance'] = serializer.instance
        return super(TPMPermissionBasedMetadata, self).get_serializer_info(serializer)

Example of metadata:

Example shows that visits could be added by partner field. If user is not allowed to create visits, POST will not appear:

Example of available instance fsm transitions:

user can either accept or reject the Visit, but can't edit any details.