Table of Contents

Post types

Kate Santo Updated by Kate Santo

Posts are possibly the most central part of the Padoq platform. Users communicate with each other through posts; admins communicate with their padoq members using posts; issues are reported through posts; payments are structured and handled as posts; etc.

There are in total 17 post types, which we'll define in this guide. If you're after a summary of what each post type is, find it in our Padoq feed and menus guide.

Find out how users interact with posts in the user version of this guide.

Prerequisites

  • You can download the iOS or Android app on your phone to see what the user sees. And you can also log in or sing up to the web app here
  • You can also see the UI by checking out the images you'll find throughout the guide
  • You will find the relevant endpoints linked and explained in this guide, but the full API is documented in Swagger UI

General notes about posts

Key endpoints

There are dozens of endpoints that either create, read, update or delete posts of different types. Many of them are linked to the generic use of posts in padoqs: a user in a padoq creates a post for the rest of the group to see and interact with. But other endpoints outside of that central stream also use posts, like the pinboard, forms or even the calendar.

Here are some of the key endpoints that interact with posts:

  • Standard actions: The createPost and editPost endpoints allow users to create and edit posts. If the post has an attachment, the createAttachment endpoint comes into play. When a padoq launches, the getPosts endpoint fills the feed. And when a user selects a specific post to look at (because they saved it to their pinboard, for example, as we explain further down), the getPost endpoint brings up all details a post can possibly have
  • Interactions and reactions: When a user interacts with a post, the logUserPostActions endpoint registers it. The payload is quite straightforward: it has a postId, a timestamp of when the action happened and an action property. The action property contains an array of the 6 possible interactions: READ_MORE, POST_EXPANDED, LINK_PRESSED, IMAGE_PRESSED, ATTACHMENT_READ, VIEWED. Beyond that when users react to a post (with a like, a dislike or a comment), the getReactions endpoint retrieves all reactions (both the count and the content of them).

Permissions

Depending on the level of access a user has and on the settings of each app, some users are not able to post anything, others are able to create only certain types of posts and other can create all types of posts. The 3 levels of permission related to posts are:

  • permittedAdminPostTypes: this captures the types of posts that the admin of a group can create. This is the full list of posts we're talking about further down in this document. This is the default and can't be updated in the UI
  • permittedPostTypes: posts that members can create. By default, members can create posts of types basic, comment, vote, vote_rs, payment_rs, event_rs, survey_rs and form_rs. Admins can allow members to create more types of posts, like surveys, via an option in the UI. This is defined in the padoq's details and can be retrieved via the getPadoq endpoint
  • permittedGuestPostTypes: the content of this property can vary wildly between apps. By default, all padoqs have a value of false in the allowGuests property, which means that there's no need to define the types of posts a guest can create. When guests are allowed, a user with the Super Admin role can define what guests can create. This information is also captured in the padoq's details and can be retrieved via the getPadoq endpoint

Post status

The status property in a post payload (in the response sent back by the getPost endpoint, for example) contains an array of 5 possible status: OPEN, CLOSED, CANCELLED, HELD, ARCHIVED.

  • A post with status open is a standard live post in a group
  • A closed status applies to form posts. If a user reports an issue, for example, and the issue is then resolved, the admin or the user can mark it as closed
  • The cancelled status only applies to event posts, when the author of the event or the admin of the group cancel the event. The event post is not actually deleted, otherwise it couldn't be marked as cancelled
  • Held is a status that applies to payment posts only, when the payment is on hold until it's verified by a third party payment provider
  • The archived status is not used

Post types

1. BASIC

This is a post without additional structured content. Find the standard post schema in the Schemas section of this page). It's the type of post that appears in a group's feed or in the user's home feed.

Here's a very common display for a basic post:

Here's how a part of the payload would look like for this example post:

{
"text": "Any updates on the internet? Mines down",
"type": "BASIC",
"public": false,
"canLike": true,
"canDislike": false,
"canComment": true,
"recipients": [
"null"
],
"display": {
"hideDisplayHeader": false,
"hideDisplayFooter": false
},
"likeCount": 20,
"dislikeCount": 0,
"commentCount": 10
}

Here are some of the properties we can spot on this post.

  • Text: it's the content of the post
  • Type: this is a basic post. Other types of post might be vote, or survey. Those have different content in their structure
  • Public: specifies whether users who aren't registered in the app can see it. The default value is false (meaning that only logged in users can see posts)
  • canLikecanDislike and canComment: these properties set whether users can do each of those things for a post, in the example above, all 3 properties are set to true. If the value was false in any of them, the relevant icon would disappear from the post footer. Both admins and members can choose to turn these on or off when they post something
  • recipients: if the user selects a number of users to share the post with, their names would appear here. If the value is null, as it is in our example, it means that all members of that padoq can see the post
  • likeCountdislikeCount and commentCount: these properties have numbers as values. Each count appears next to the relevant icon in the post footer, unless the count is "0", in which case there will be nothing next to the icon. In our example, there are 20 likes, 0 dislikes and 10 comments. These values are returned by the getReactions endpoint

Beyond that, basic posts also include posts that have video, images, document attachments and mentions to other personas. This type of data is stored in the mentions and attachments properties.

2. COMMENT

This is a comment to a post. It typically appears underneath the post it refers to. And that "parent" post is specified in the refersTo property within the PostRs schema (find it in the Schemas section of this page). Comments are linked to their post via an ID in that property, but if the value of that property is null, this means you're looking at a post, not a reply or comment.

The content of all comments to a post is loaded and displayed by calling the getReplies endpoint.

3. VOTE

A post of type vote is a post with structured content that includes a specific payload requiring and returning key information like checklist (to allow users to update their response to the poll at any time) or voteTrigger (which allows the author of the post to define an action they want to trigger when a user submits their response to the poll).

Another important property in a vote payload is publishResults, which specifies whether members who have voted can see how others voted.

4. VOTE_RS

This is a response to a vote post. It behaves very similarly to vote posts, with some properties that become very important in a response: refersTo, which links the response to the right vote post via an ID.

When members are allowed to change their vote after having submitted it, the updatePostReply endpoint comes into play. It takes 5 compulsory parameters:

  • name: the padoq where the vote post lives
  • postId: the post that contains the reply we're looking for
  • postVersion: the version of the post we're looking for
  • replyId: the ID of the reply within that post
  • replyVersion: the version of the reply we're updating

5. SURVEY

This is a post with structured content that includes information like questions (which defines what the survey is made of and requires each question to be unique and at least one question to be answered before the survey is submitted).

Surveys typically appear in a group's feed and they behave similarly to votes. The main difference is that, in surveys, the answers are not predefined. Users have to type in their answer to each question.

Survey payloads have 4 properties:

  • type: the first compulsory property. Its value is a string determining the type of survey we're looking at. The 2 only possible values are: SURVEY and SURVEY_RS
  • publishResults: this is a boolean that determines whether users can see results once they submit their response
  • questions: this is the second and last compulsory property in the payload. It's an array of objects, and each object is a question in the survey

6. SURVEY_RS

A response to a survey post has the same structure as the survey post itself. The key difference is that the survey response will include the user's answers in the questions property. Responses can't be submitted unless at least 1 question has been answered.

When the author of the survey collects and views answers, the getReplies endpoint is called. Depending on whether the publishResults property is true or false, members may or may not be able to view answers.

7. TEMPLATE

This is a post with structured content that allows functionality like issue reporting. Find out more in this separate guide about forms and templates.

8. FORM

This is a post that works with templates and allows for detailed and trackable information collection. Find out more in Create and Manage Forms (Information Collection).

9. FORM_RS

This is a response to a form post. When a user reports an issue via a form, some relevant keys in the payload would look like this. Imagine a tenant called Juliet Smith is reporting a broken fridge in her flat. The FORM_RS for her issue would have data in the structuredContent property such as this:

{
"id":"366e8827-7842-11eb-ba57-005056b634b0",
"title":"Re: Appliances",
"type":"FORM_RS",
"posted":"2021-02-26T14:52:14.131Z",
"effectiveTimestamp":"2021-02-26T14:52:14.131Z",
"authorId":"29248ac4-360a-416e-ac7f-0c7e60155d38",
"authorDisplayName":"Juliet Smith",
"authorAvatarUri":"https://avatar/1234567890",
"status":"OPEN",
"version":1,
"structuredContent":{
"type":"FormPayload",
"sections":[
{
"questions":[
{
"type":"InfoItem",
"label":"Details of broken appliance",
"answer":"Broken fridge "
},
{
"type":"InfoItem",
"label":"When did the issue start?",
"answer":"Monday"
}
]
},
{
"questions":[
{
"type":"ChoiceInfoItem",
"label":"Is the issue dangerous to you or others?",
"answer":"No",
"options":[
"Yes",
"No"
]
}
]
}
]
}
}

10. EVENT

This is a post with structured content that includes information like amount (if the event is paid), frequency (if the event is recurrent) or maxAttendees (to limit how many people can attend the event). In the UI, it might look like this:

11. EVENT_RS

This is a response to an event post. In the UI example above, when the user taps 'Accept', [what happens? What gets updated?]

When the user opens their calendar, the getMemberCalendar endpoint is called. It takes 3 compulsory parameters:

  • name: the name of the padoq we're finding events for
  • alias: the member alias we're checking
  • Accept: the type of response the endpoint accepts. In this case, it's data of type text/calendar, as opposed to the JSON format most endpoints accept

12. PAYMENT_RQ

This is a post to request payment. It has structured content that includes information like maxQuantity (to establish the maximum number of items that can be purchased, in a shop-style app) or productCode (which specifies the vendor's code or ID for the product).

This is also the type of post that can be sent directly to a member of a padoq to request a direct payment. The sendPostReminder endpoint is not exclusive to payments, but it's very handy for this type of post: the author of the payment request can send reminders for the intended user to pay.

13. PAYMENT_RS

This is a response to a payment post: when a user sends payment by replying to a payment_rq post. One of the properties in the payload that is unique to the response is paymentProvider. This collects and sends information about the payment provider used for a transaction.

14. NOTE

This is a post with structured content linked to the pinboard. Its payload includes properties like:

  •  type, which can have 1 of 3 values: basic, pin and reminder. A basic note is created from scratch by the user, a pin is a saved post from a padoq and a reminder is like the basic type, but with date and time added to it. Notes of type basic and reminder are the only ones in the collection of post types that aren't linked to a padoq
  •  expires, which has a date-time string as its value and is relevant for reminders
  • link, which is relevant for notes of type pin. This link refers to the post that has been pinned, so if the user taps the pin, they are taken to the original post via that link

There are some endpoints that are relevant for this type of post. Users can organise their notes with tags like "Important", "Trips" or whatever categories work for them. So when the pinboard is loaded (via the getUserNotes endpoint), the getUserTags endpoint is called to retrieve those tags. Users can also update their tags. This is done via the updateUserTags endpoint.

For notes of type basic and reminder users can create them, edit them (the content or the tags associated to the note) and delete them. Notes of type pin can't be created nor edited, only deleted.

15. REMINDER

This is 1 of the 3 types of note mentioned above. The main difference between a reminder and the other types of notes is that a reminder carries a timestamp (and therefore has an expiry date). The app uses that timestamp to send a push notification to the user with the reminder.

16. OFFER

This is a post with a payload that serves information about a product. The user can use that information to redeem codes and benefit from the offer. The offer can be a discounted price, for example.

In the structured content part of the payload, offer posts have properties like:

  • termsAndConditions: which specifies the terms of the offer
  • merchantInformation: which tells the user about the merchant making the offer
  • previousAmount: which specifies, optionally, the old price of the product on offer, relevant if the offer is a discount

At Padoq, we have developed this type of post with a specific customer in mind, so it's not used across the platform and you're unlikely to see examples of offers in our apps.

17. OFFER_RS

This is a response to an offer post, so it's structured very similarly to offer posts. The main difference is that the response will include details about the user who is redeeming a code, time stamps of when it happens, etc.

How did we do?

App menus

Super Admin Dashboard - Issue reports

Contact