Managing a padoq

When a user creates a padoq, they can customise a bunch of things: the padoq's colour, the privacy level, the tags members can use, etc. And once the padoq is created, these settings can be edited at any time from My padoqs > Admin > Settings or from the Super Admin page.

In this guide, we review how our APIs handle settings and edits to padoqs and their content.

See for yourself

• You can download the iOS or Android app on your phone to follow this journey along. And you can also log in or sign up to the web app here
• You can also follow along by checking out the images or code snippets in this guide
• And you will find the relevant endpoints linked and explained in this guide, but the full API is documented in Swagger UI

Prerequisites

• For some padoq settings to display in the UI, the padoq needs its official and qrCodesEnabled parameters setting to true. This can only be done by an admin at Padoq (i.e. padoqs are not official by default). Read more on this further down in this guide

Main settings

All edits to a padoq done from the main settings page are completed via the updatePadoq endpoint. This endpoint receives a request that includes the fields that need updating. Its response are basic success or failure messages.

1. Padoq info
   1. By using the options in the UI, the admin can update different aspects of the padoq like the title, description, location, colour and interests. There is another relevant property here called categories, which is how interests are called in branded apps. Categories are more relevant to the client's business, but they behave the same way as interests. Both categories and interests group padoqs together and make it easier for users to find relevant content. The explore functionality uses this information heavily. Find out more in our guide: Explore

      {
        "title": "My Place",
        "colour": "soft_pink",
        "description": "A description of this padoq.",
        "interests": [
          "Music",
          "Food & Drink",
          "Travel"
        ],
        "location": {
          "name": "Europe/Manchester",
          "coordinates": [
            53.466667,
            -2.233333
          ]
        },
        "categories": [
          "East side",
          "North east"
        ],
      }

   2. A padoq admin can also upload documents for all members to access. This is done via 2 endpoints: createPadoqDocument and uploadPadoqDocument
2. Padoq tags
   These are filters that allow users to see posts with specific tags like "Announcements" or "Events". Admins can create new tags when they create a post or from the tags section in their padoq. However they do it, the updatePadoq endpoint is called and the content of the permittedRichTags property is updated.
   By default, all padoqs have an allowPostTags property with a value of true, which means that members can tag their posts with a # followed by the tag name. Tags group posts together and behave like filters.
3. Privacy
   The settings in this part of the UI interact with the minimumAge, privacyLevel and visible properties in the padoq schema:

   { 
     "minimumAge": 18,
     "privacyLevel": "PRIVATE",
     "visible": true
   }

   The visible property is retrieved via the getPadoqRegistrationDetails endpoint
   There is also a toggle for the admin to choose whether they want to approve requests to join their padoq. Read more about privacyLevel and how requests to join are handled in our guide.
4. Required information
   The creator of the padoq can set up questions for members to answer as they join. The admin can make these questions compulsory or not. In the code, the answers to the required information lives in the personaDetails schema. Admins can see the answers by all members via the getPersonas endpoint.
5. Members
   Padoq admins can view, invite and delete members to their padoq:
   1. Viewing members is done via the getPersonas endpoint. It takes one compulsory parameter (the name of the padoq), accepts a few optional parameters (like a role to filter by) and returns a list of all the members of the padoq
   2. Inviting members is done via 1 of 2 endpoints: createPadoqInvitation (which sends an email to the specified address) or createPadoqInvitationLink (which generates a deeplink to share)
   3. Deleting members is done via the deletePersona endpoint, which takes two parameters (the name of the padoq and the alias of the persona to delete) and returns simple success or failure messages
6. Permitted post types
   The permittedPostTypes and guestPermittedPostTypes properties in a padoq define the types of posts that members and guests can create. In standard padoqs, the permittedPostTypes property has a default value. The value of the guestPermittedPostTypes property is different for each app, depending on the requirements:

    "permittedPostTypes":[
         "BASIC",
         "COMMENT",
         "VOTE",
         "VOTE_RS",
         "PAYMENT_RS",
         "EVENT_RS",
         "SURVEY_RS",
         "FORM_RS"
      ],
    "permittedGuestPostTypes":[
         "PAYMENT_RS",
         "FORM_RS"
      ]

   Admins can update the default list of post types allowed for members of a padoq. This is done via the updatePadoq endpoint.

Super Admin settings

Some of the more complex settings of a padoq live in a separate space: the Super Admin page (only available on web).

There are 2 types of settings in a padoq that are controlled from the Super Admin page: those that live in the displayOptions object and those that are managed by someone at Padoq.

The displayOptions object

The overall appearance of a padoq feed on mobile is controlled by the displayOptions object via the Super Admin page.

The displayOptions object in the padoq's schema can be retrieved via the getPadoq endpoint and it might look like this:

"displayOptions": {
    "options": [
      "HIDE_PADOQ_MENU"    ]
  }

This object has a very simple structure: one property that contains an array as its value. This array is a list of settings that change the UI. The admin of the padoq can update the content of the array via the web app. And each edit is done by calling the updatePadoq endpoint and sending the updated object in the response. Each option added or removed from the array will have an effect in how the padoq feed is displayed. There are 17 possibilities in this array:

 "options": [ 
    "HIDE_PADOQ_MENU", 
    "HIDE_PADOQ_AVATAR", 
    "HIDE_MEMBER_COUNT", 
    "HIDE_CREATE_POST", 
    "HIDE_SEARCH", 
    "HIDE_ACTION_MENU", 
    "HIDE_DOCUMENTS", 
    "HIDE_SETTINGS", 
    "HIDE_CALENDAR", 
    "HIDE_CATEGORIES", 
    "HIDE_MEMBER_LIST", 
    "HIDE_INVITE_MEMBER", 
    "HIDE_PADOQ_SETTINGS", 
    "HIDE_REQUIRED_INFO", 
    "HIDE_PADOQ_CATEGORY", 
    "HIDE_PADOQ_INFO", 
    "SHOW_POST_TABS" 
]

For the admin, the array of options looks like this in the Super Admin page:

Special Super Admin settings

There are items that appear in a padoq feed that are more complex and can't be added or removed by the admin of the padoq unless there has been some work done beforehand. These are things like the button to report issues or book rooms in property apps.

There are 3 key properties in the padoq schema that allow complex features to appear: official, qrCodesEnabledand bookingInfo. These are updated through the standard updatePadoq endpoint, but they require Ops authorisation to be edited -that's the type of authorisation Padoq admins will have.

{
    "official": true,
    "qrCodesEnabled": true,
    "bookingInfo": { }
}

For the feature to report issues to be active, official and qrCodesEnabled need to be true. Only someone at Padoq can do that. However, once they are set to true, the padoq admin can manage the full report issue flow via the Super Admin page: create, update, delete and report on issues. Ops access is not needed for that. Find out more about forms in our guide: Create and Manage Forms (Information Collection).

On top of that, when there is information inside the bookingInfo object, then users can also book rooms and other things like appointments. Once this is turned on, the admin can set how members of their padoq interact with bookings. This is done via the Super Admin page (Bookings tab). In the example below, members can only book 3 times in 24 hours or 12 times in 28 days.

This object might look like this when it's populated:

{
    "bookingInfo": {
        "bookingRestrictions": {
            "slot": {
                "units": "HOURS",
                "maxDuration": 1,
                "minDuration": 1
            },
            "quantity": [
                {
                    "period": 24,
                    "allowance": 3,
                    "periodUnits": "HOURS",
                    "allowanceUnit": "HOURS"
                },
                {
                    "period": 28,
                    "allowance": 12,
                    "periodUnits": "DAYS",
                    "allowanceUnit": "HOURS"
                }
            ]
        },
        "appointmentsDisabled": false
    },
}