Community settings

Some behaviors of the community UI are set per community in the Octopus back office rather than in your code. The SDK reads the community configuration at startup and on each configuration refresh, and adapts its screens. This page lists each setting and what the SDK does with it. To change a setting for your community, contact Octopus.

Before you begin

• Complete the Quickstart: the SDK is initialized and the community UI opens.
• Check the minimum SDK version of each setting you plan to use: the versions are listed under each section and in Platform support.
• If your app declares app-managed profile fields, read App-managed profile fields first: the profile field lock does not block them.

Content options

Android ≥ 1.12.1iOS ≥ 1.12.3Flutter ≥ 1.12.2React Native ≥ 1.13.0Unity ≥ 1.12.2

Content options turn off specific creation controls, separately for posts, comments and replies. They govern what members can add to new content, not how existing content is displayed. Your app has nothing to integrate.

What is controlled

Each of these controls can be turned off on its own:

Option	Effect when turned off
Post pictures	Hides the add-picture button in the post editor.
Post polls	Hides the create-poll button in the post editor, and the poll prompt on the member's own profile.
Comment pictures	Hides the add-picture button in the comment field.
Reply pictures	Hides the add-picture button in the reply field. Comment and reply pictures are set separately.

Images in a post that your app prefills, for example through a share or a deep link, are not affected by the post pictures option.

Default behavior

Every option is on by default. A community that sets no content options shows all the creation controls.

Platform details

Android

The SDK applies the options itself. To read them in your own UI, for example to hide a matching control, collect the community configuration:

import com.octopuscommunity.sdk.OctopusSDK
import com.octopuscommunity.sdk.domain.model.CommunityConfig

OctopusSDK.communityConfigRepository.getCommunityConfigFlow().collect { config ->
    val options: CommunityConfig.ContentOptions = config?.contentOptions ?: CommunityConfig.ContentOptions()
    options.post.enablePictures    // false hides the add-picture button in the post editor
    options.post.enablePolls       // false hides the create-poll button
    options.comment.enablePictures // false hides the add-picture button in comments
    options.reply.enablePictures   // false hides the add-picture button in replies
}

iOS

The SDK applies the options itself. The iOS SDK does not expose them to your app, so there is nothing to read or configure.

Flutter

The SDK applies the options itself, and there is no Flutter API to read them. The ContentOptions class exists only for OctopusSDK().debugOverrideContentOptions(), a debug hook that lets you test each option locally without changing the community configuration.

React Native

The SDK applies the options itself, and there is no React Native function to read them. The ContentOptions type exists only for debugOverrideContentOptions(), a debug hook that lets you test each option locally without changing the community configuration.

Unity

The SDK applies the options itself. There is nothing to call from Unity.

---

Profile field lock

Android ≥ 1.12.1iOS ≥ 1.12.3Flutter ≥ 1.12.2React Native ≥ 1.13.0Unity ≥ 1.12.2

The profile field lock sets whether members can edit their nickname, avatar and bio in the community. The SDK adapts the profile screens to the lock. Your app has nothing to integrate. A community that sets no lock keeps every field editable.

Lock states

Each field is in one of three states:

State	Meaning
Editable (default)	The field is shown and members can change it.
Read-only	The current value is shown, but members cannot change it in the community.
Disabled	The field is hidden entirely. Only the bio can be disabled: the nickname and avatar are either editable or read-only.

Your app cannot change the lock, apart from the debug overrides described in Configuration. It always reflects the community configuration.

Per-field behavior

Nickname

• Editable: shown and editable. Members confirm their nickname before their first post.
• Read-only: shown but not editable. The SDK skips the first-post nickname confirmation, and members post with the nickname the community assigned them.

Avatar

• Editable: shown with the add or edit overlay. Tapping it opens the edit flow.
• Read-only: shown as a plain image, with no overlay. Tapping it does nothing.

Bio

• Editable: shown, with an "Add a bio" prompt when it is empty. Tapping it opens the edit flow.
• Read-only: the current bio is shown as plain text, with no "Add a bio" prompt.
• Disabled: the bio section is removed from the profile.

Edit profile screen

The edit profile screen shows only the editable fields. Read-only and disabled fields are absent, not greyed out. The Edit profile button on the profile stays visible while at least one of the three fields is editable, and is hidden when all three are locked.

Interaction with app-managed fields

A field that your app declares as app-managed is not blocked by the lock. When a member tries to edit it, the SDK asks your app to open its own profile editor, as usual. The lock applies only to the fields your app does not manage.

Configuration

Android

The SDK applies the lock itself. To read it in your own UI, collect the community configuration. CommunityConfig.profileFieldsLock holds a ProfileFieldLockState for each field, EDITABLE, READ_ONLY or DISABLED, and defaults to ProfileFieldsLock.AllEditable when the community sets no lock.

import com.octopuscommunity.sdk.OctopusSDK
import com.octopuscommunity.sdk.domain.model.ProfileFieldLockState
import com.octopuscommunity.sdk.domain.model.ProfileFieldsLock

OctopusSDK.communityConfigRepository.getCommunityConfigFlow().collect { config ->
    val lock: ProfileFieldsLock = config?.profileFieldsLock ?: ProfileFieldsLock.AllEditable
    val canEditBio = lock.bio == ProfileFieldLockState.EDITABLE
}

iOS

The SDK applies the lock itself. The iOS SDK does not expose it to your app, so there is nothing to read or configure.

Flutter

The SDK applies the lock itself, and there is no Flutter API to read it. The ProfileFieldsLock class and the ProfileFieldLockState enum (editable, readOnly, disabled) exist only for OctopusSDK().debugOverrideProfileFieldsLock(), a debug hook that lets you test each state locally without changing the community configuration.

React Native

The SDK applies the lock itself, and there is no React Native function to read it. The ProfileFieldsLock type and ProfileFieldLockState ('editable' | 'readOnly' | 'disabled') exist only for debugOverrideProfileFieldsLock(), a debug hook that lets you test each state locally without changing the community configuration.

Unity

The SDK applies the lock itself. There is nothing to call from Unity.

---

Explicit terms acceptance ≥ 1.13.0

Android ≥ 1.13.0iOS ≥ 1.13.0Flutter ≥ 1.13.0React Native ≥ 1.13.0Unity ≥ 1.12.8

By default, a legal notice sits at the bottom of the post, comment and reply editors, and members accept the terms implicitly when they publish. A community can instead require members to accept its legal documents (terms of use, privacy policy, community guidelines) explicitly, in a sheet shown at their first contribution. Your app has nothing to integrate: the SDK shows the right experience from the community configuration.

There are three modes:

Mode	What members see
Implicit (default)	The legal notice at the bottom of the editor. Publishing accepts the terms.
Explicit, one checkbox per document	A sheet at the first contribution, with one required checkbox for each legal document.
Explicit, single checkbox	The same sheet, with one combined checkbox and a notice about the privacy policy.

In an explicit mode, the publish button stays disabled until the required boxes are ticked. On confirmation, the content is published and the consent is recorded once for the member, so the sheet never shows again. Dismissing the sheet leaves the editor as it was and publishes nothing.

---

Comments tab visibility ≥ 1.14.0

Whether members can see the Comments tab on other members' profiles and activity is a back-office setting of your community, off by default: contact Octopus to turn it on. The SDK screens follow it on every platform, with no code in your app. Members always see the Comments tab on their own profile, whatever this setting.

Next steps

• Connect your users: declare app-managed profile fields.
• Unified Profile: open member profiles from your app.
• Display the community: host the community screens.