Creation requires an errands.generalerrandtype, which defines the kind of errand and which fields are allowed or required. Optionally provide errands.generalerrandsubtype for a more specific type. An errand type (and sub-type) can be restricted to certain object types via allowed_connection_types.
Some validation depends on the client application. Send the header X-PIGELLO-CLIENT-CT with value <environment>,mypages,<version> (e.g. prod,mypages,1.0.0) to identify a "My Pages" client.
If you don't know the object type the user is creating the errand for, use the first example. If you do know the object type (e.g. objects.apartment), use the second example.
You can filter by portal using the allowed_in_portals parameter (0, 1, 2, or 3 depending on your client).
Endpoint: GET /errands/generalerrands/configurations/generalerrandtype/list/
If you don't know the object type:
GET /errands/generalerrands/configurations/generalerrandtype/list/?_page=1&_page_size=500Query parameters:
- _page — Page number (e.g. 1)
- _page_size — Page size (e.g. 500)
If you do know the object type (e.g. objects.apartment):
GET /errands/generalerrands/configurations/generalerrandtype/list/?_page=1&_page_size=500&allowed_connection_types__in=objects.apartmentQuery parameters:
- _page — Page number (e.g. 1)
- _page_size — Page size (e.g. 500)
- allowed_connection_types__in — Content type(s) the errand can be bound to (e.g.
objects.apartment)
Endpoint: GET /errands/generalerrands/configurations/generalerrandsubtype/list/
GET /errands/generalerrands/configurations/generalerrandsubtype/list/?_page=1&_page_size=500&errand_type__in=<type-id-1>,<type-id-2>Query parameters:
- _page — Page number (e.g. 1)
- _page_size — Page size (e.g. 500)
- errand_type__in — Comma-separated errand type IDs from step 1
On errands.generalerrandtype and errands.generalerrandsubtype, the attributes segments, realestates, companies, and external_clients define which entities an errand can be bound to. Only show types and sub-types where these match the object the errand is created for.
- If
overrides_object_connection_restrictionsistrueon a sub-type, the sub-type overrides the errand-type's filters. - Empty filters values on the errand-type/errand-sub-type mean no restriction.
- If multiple values or multiple filter types are set, the object need only match one.
Whether an attribute on the general errand is writable or required is configured on the type (and overridden by sub-type when set).
Use the configuration attributes on the type/sub-type. If a sub-type has a non-null value, it overrides the type.
Configuration values are arrays of integers (e.g. ORGANIZATION_ALLOW, CUSTOMER_REQUIRE).
For a "Customer Pages" client, you need 2 or 3 to allow/require the field. Attributes controlled include description_configuration, object_connection_configuration, creator/reporter configuration attributes, etc.
Also make sure to respect allowed_in_portals and allowed_connection_types.
Create the errands.generalerrand first. After that you can attach files and set custom field values.
See API reference for errands.generalerrand
The errand-type (and sub-type) also control whether images, film recordings, or other files can be attached (images_configuration, film_recordings_configuration, files_configuration).
Attach files by creating errands.generalerrandfile entities linked to the errand.
- Determine which custom fields apply by retrieving errands.customerrandfieldinclusion with filter on
general_errand_type=<type-id>. - Retrieve field definition information from errands.customerrandfieldtype with
id__in=<field-type-id-1>,<field-type-id-2>based on the errands.customerrandfieldinclusion. - Retrieve existing custom field values for an errand from errands.customerrandfieldvalue.
- Submit/update values with errands.customerrandfieldvalue.
The required attribute on errands.customerrandfieldtype defines whether a value is required.