Skip to main content

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:

OptionEffect when turned off
Post picturesHides the add-picture button in the post editor.
Post pollsHides the create-poll button in the post editor, and the poll prompt on the member's own profile.
Comment picturesHides the add-picture button in the comment field.
Reply picturesHides 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.

Image-and-poll posts and optional text​

Android ≥ 1.15.0iOS ≥ 1.15.0Flutter ≥ 1.15.0React Native ≥ 1.15.0Unity ≥ 1.15.0

A post can carry an image and a poll together. If the community makes post text optional, an image post can be published without text, with or without a poll. A post without an image still needs text, including a poll alone. The SDK applies this configuration automatically.

Platform details​

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.post.textRequired      // false allows an image post without text (since 1.15.0)
    options.comment.enablePictures // false hides the add-picture button in comments
    options.reply.enablePictures   // false hides the add-picture button in replies
}

Since 1.15.0, a post can carry an image and a poll together, including a prefilled image: the image appears above the poll. CommunityConfig.ContentOptions.PostOptions.textRequired defaults to true. When it is false, an image post can be published without text, with or without a poll; blank text is omitted. A post without an image still needs text, including a poll alone. When supplied, text still needs 10 characters (1 with a poll), up to 5000. The no-argument and two-flag PostOptions constructors and copy() keep text required.

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:

StateMeaning
Editable (default)The field is shown and members can change it.
Read-onlyThe current value is shown, but members cannot change it in the community.
DisabledThe 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​

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
}

Nickname choice ≥ 1.15.0​

Since 1.15.0, members who have not confirmed a nickname choose it before their first post, comment or reply; the SDK sends the waiting contribution after confirmation. CommunityConfig.forceNicknameChoice defaults to false (generated nickname prefilled); true starts with an empty field. A signed-in member whose nickname is app-managed, locked or already confirmed skips this screen. Back cannot skip it; after a failed confirmation, closing keeps the draft without sending it.

For a custom profile editor, the new ProfileRepository.updateProfile overload takes:

  • newProfile (CurrentUserProfile): the desired profile.
  • previousProfile (CurrentUserProfile?): the previous profile, or null.
  • findAvailableNickname (Boolean): whether the server should choose an available nickname.
  • wantNicknameSuggestions (Boolean): set true to request alternatives when the nickname is taken.
// Call from a coroutine, for example inside viewModelScope.launch { }
val result = OctopusSDK.profileRepository.updateProfile(
    newProfile = editedProfile,
    previousProfile = previousProfile,
    findAvailableNickname = false,
    wantNicknameSuggestions = true,
)

A taken nickname returns ProfileUpdateError.NicknameError.AlreadyUsed.suggestions (List<String>); it is empty unless suggestions were requested. UpdateProfileUseCase has the equivalent four-argument overload (oldProfile instead of previousProfile); the old three-argument calls remain and request no suggestions.

Recompile prebuilt code that constructs or copies CommunityConfig, or implements ProfileRepository or CommunityConfigRepository; Java callers of the configuration constructor or copy must pass the new arguments.

Since 1.15.0, CommunityConfig.consentTexts carries the community's own markdown wordings in the member's language for the consent shown before a member's first contribution: CommunityConfig.ConsentTexts.Implicit(notice), MultiCheckbox(termsLabel, privacyLabel, rulesLabel) or SingleCheckbox(label, belowText). Only the case matching termsAcceptanceMode applies. Missing or empty texts keep the SDK wording; links, bold, italic and line breaks are supported. Configuration and stored consent texts migrate automatically on upgrade.

The SDK routes links in these wordings through the host's onNavigateToUrl. If you embed com.octopuscommunity.sdk.ui.comments.components.OctopusItemInputField yourself, wire its new trailing onNavigateToUrl: (String) -> Unit parameter to your URL handler: its default does nothing. Recompile prebuilt code that calls this composable or constructs/copies CommunityConfig.

Since 1.15.0, the explicit consent sheet scrolls while its button stays at the bottom. The implicit notice scrolls inside a zone capped at five and a half lines and one fifth of the window height, keeping the editor usable at large font sizes. No integration change is needed.

Nickname choice before contributing​

Android ≥ 1.15.0iOS ≥ 1.15.0Flutter ≥ 1.15.0React Native ≥ 1.15.0Unity ≥ 1.15.0

Members who have not confirmed their nickname choose it before their first post, comment or reply. Members whose nickname is app-managed, locked or already confirmed skip this screen. The SDK keeps the draft until confirmation. Your app has nothing to integrate; the community controls whether the generated nickname is prefilled or the field starts empty.

Android ≥ 1.15.0iOS ≥ 1.15.0Flutter ≥ 1.15.0React Native ≥ 1.15.0Unity ≥ 1.15.0

The legal notice and consent sheet use the community's wordings in the member's language. Markdown links, bold and italic are supported, and missing or empty texts keep the SDK wording. Links use your existing URL callback. The consent sheet scrolls while its confirmation button remains accessible. Your app has nothing to integrate; wordings are configured for the community.

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​