[SHIVANSHGARG07]

Adds a change_activity_visibility option to USER_DISABLED_FEATURES / EXTERNAL_USER_DISABLE_FEATURES so admins can enforce public user activity, e.g. for company instances that require it.

When set, the "Hide Activity" checkbox is locked and every user's activity is treated as public, including users who had hidden it before. The stored preference is kept, so it applies again if the option is removed. The API settings endpoint rejects hiding activity (and changing a locked full name, which was previously unguarded).

Fixes #37961

Screenshots

Before

After

Config used

[admin]
USER_DISABLED_FEATURES = change_activity_visibility

[SHIVANSHGARG07]

Hello @maintainers can you please review this.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.

[bircni]

• The API isn't guarded. routers/api/v1/user/settings.go:57 still applies HideActivity from PATCH /user/settings, so any user can bypass the lock through the API.
  • The option isn't documented. custom/conf/app.example.ini:1729-1730 lists change_username and change_full_name but not change_activity_visibility.

--> fixing it

[bircni]

Pushed a few follow-ups on top:

• Locking change_activity_visibility now enforces public activity for everyone, including users who had hidden it before. The stored preference is kept and applies again if the lock is lifted.
• Feeds, heatmaps, profile/settings pages and the API settings response use the effective value; the SQL filter handles NULL login_type and is skipped when everyone is forced public.
• PATCH /api/v1/user/settings returns 404 when trying to hide activity or change the full name while locked (the latter was previously unguarded), consistent with other disabled-feature API guards.
• The disabled checkbox now shows a hint explaining the admin lock.
• Documented change_activity_visibility (and the missing change_username/change_full_name) in app.example.ini.
• Tests cover a previously-hidden user becoming public, the stored preference being kept, and the API guards.

Assisted by Claude Code (claude-opus-5-5)

[bircni]

lgtm now - pls also update the docs repo

[SHIVANSHGARG07]

lgtm now - pls also update the docs repo

Done https://gitea.com/gitea/docs/pulls/624

[wxiaoguang]

It's really a strange design that "disabling change_activity_visibility" means "force public".

And future developers need to keep remembering that KeepActivityPrivate / keep_activity_private should never be used. It is very fragile.

[wxiaoguang]

Maybe you need to think more about design.

For example: there is "repo force private", then

• FORCE_PUBLIC: force every Repository to be public #24059

[wxiaoguang]

Need a better design

[SHIVANSHGARG07]

Need a better design

will share one design doc and start working after approved

[SHIVANSHGARG07]

I redesigned this PR based on the feedback about change_activity_visibility.

The activity policy is now explicit: [service] FORCE_PUBLIC_ACTIVITY = false. The overloaded USER_DISABLED_FEATURES entry has been removed. KeepActivityPrivate remains the user's stored preference, while IsActivityPrivate() and ActivityPublicCond() calculate effective visibility consistently for profiles, feeds, heatmaps, and APIs.

When force-public mode is enabled, the web/API settings cannot enable private activity, the UI control is disabled, and the stored preference is preserved. Disabling the policy restores the user's previous preference.

I also updated configuration documentation, generated Swagger, unit/integration coverage, and tests for API, UI, activity feeds, heatmaps, and preference restoration. The branch was merged with upstream main normally and pushed in commit c0e7c9275b.

Please review the redesigned architecture and mergeability.

Assisted-by: Augment Agent: GPT-5.6 Luna

[wxiaoguang]

1. I believe it needs a string value but not boolean, to make it flexible
   • enhance: allow admins to enforce public user activity #40002 (comment)
2. I don't think we should take these IsActivityPrivate tricks. You can simply do this:
   • When Gitea web starts, check whether the config value has changed (old value is saved into table app_state)
   • If the config setting changed, update the table to make sure all users are in correct state.