Add PublicReleaseDownloads repository setting to allow direct release downloads without authentication for Limited visibility repos. Adds migration v369, checkbox in Advanced Settings (only shown for Limited repos with releases enabled), and updates attachment serving logic to check HasPublicReleases. Moves release download routes outside auth requirement when public downloads enabled. Complements existing pages config PublicReleases toggle.
Add OwnerDisplayName field to Repository model to allow custom display name for repository owner (e.g., "John Smith" instead of username). Used in license generation, social cards, and other public-facing contexts. Includes migration v368 to add column, UI in repository settings, and updates to license creation and social card rendering to use display name when available.
Add repository setting to control anonymous access to app integration endpoints (issue submission, update checks). When enabled (default), the desktop app can access these endpoints without authentication. When disabled, vault token authentication is required.
This provides granular control over app integration access, allowing repository owners to enforce full authentication on sensitive repositories while maintaining ease of use for public/limited repos.
Changes include:
- New PublicAppIntegration boolean field on Repository model
- Database migration v365 to add the field (defaults to true)
- Repository settings UI to toggle the feature
- Updated checkVaultTokenForRepo to respect the setting
- Security enhancement: IssueStatusJSONEndpoint now only returns app-submitted issues to anonymous users
Changes blog tab visibility check from generic IsWriter to specific CanWrite permission for code unit. Adds help text to blog and subscription settings explaining behavior and access requirements.
Adds comprehensive blog post system for repositories with draft/public/published status, featured images, tags, and subscriptions. Includes database models, migrations, CRUD operations, email notifications, explore page, and full UI templates for creating, editing, and viewing blog posts.
Adds new social card customization options including solid color backgrounds and custom background images with Unsplash integration. Introduces new database fields for storing color, background image URL, and Unsplash attribution. Adds media kit settings page for repository-level social card configuration.
Implement Open Graph social card image generation with customizable themes. Cards are dynamically rendered with repository name, description, owner avatar, and GitCaddy branding.
Features:
- Three built-in themes: dark (default), light, and colorful
- 1200x630px cards optimized for social media platforms
- Avatar fetching with caching and fallback to default
- Text wrapping and truncation for long descriptions
- Repository settings UI for theme selection
- Migration to add social_card_theme column
Technical implementation:
- Uses golang.org/x/image for rendering with Inter font family
- Singleton renderer pattern for font reuse
- Endpoint: /:owner/:repo/socialcard.png
- Integrates with Open Graph meta tags in head template
Add Inter font files (Regular and Bold) and GitCaddy logo asset.
Add repository setting to hide files and folders starting with "." from non-admin users in the code browser. Admins can still see dotfiles displayed dimmed. Includes database migration, settings form, filtering logic for tree views and file listings, and locale strings.
Introduces a new "limited" visibility level between public and private. Limited repos are publicly browseable but restrict clone, fork, and archive downloads to collaborators only. Adds database migration, UI controls in settings, enforcement in git HTTP and SSH handlers, and corresponding locale strings.
Adds a GroupHeader field to repositories allowing them to be grouped under custom headers on organization pages. Includes database migration v333, form handling, and grouped/ungrouped view toggle in the UI.
- Add repository display title field shown in header and explore listings
- Add license settings page with predefined license types
- Auto-create LICENSE.md when license type is selected
- Show license in repo sidebar with link to LICENSE.md
- Add API header link option in theme settings
- Default explore/organizations sort to alphabetical
- Show org DisplayName only in /explore/organizations
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
The "autofocus" was abused or misbehaved:
1. When users visit a page but they are not going to change a field,
then the field shouldn't get "autofocus"
* the "auth" / "user" page: in most cases, users do not want to change
the names
* see also the GitHub's "settings" page behavior.
2. There shouldn't be duplicate "autofocus" inputs in most cases, only
the first one focuses
3. When a panel is shown, the "autofocus" should get focus
* "add ssh key" panel
This PR fixes all these problems and by the way remove duplicate
"isElemHidden" function.
This PR tries to finally fix the bug mentioned in #30011 and #15504,
where the user repo limit is checked when creating a repo in an
organization.
Fix#30011
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: TheFox0x7 <thefox0x7@gmail.com>
Follow #33127Fix#8649, fix#639
This is a complete solution. A repo unit could be set to:
* Anonymous read (non-signed-in user)
* Everyone read (signed-in user)
* Everyone write (wiki-only)
When transferring repositories that have issues linked to a project
board to another organization, the issues remain associated with the
original project board. This causes the columns in the project board to
become bugged, making it difficult to move other issues in or out of the
affected columns. As a solution, I removed the issue relations since the
other organization does not have this project table.
Fix for #31538
Co-authored-by: Jason Song <i@wolfogre.com>
`overflow-wrap: anywhere` is a superior alternative to `word-wrap:
break-word` and we were already setting it in the class. I tested a few
cases, all look good.
This PR split the `Board` into two parts. One is the struct has been
renamed to `Column` and the second we have a `Template Type`.
But to make it easier to review, this PR will not change the database
schemas, they are just renames. The database schema changes could be in
future PRs.
---------
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: yp05327 <576951401@qq.com>
When creating a repo, the "FORCE_PRIVATE" config option should be
respected, `readonly` doesn't work for checkbox, so it should use
`disabled` attribute.
- `.text-thin` and `.text-italic` are not present in CSS so were doing nothing and I removed them.
- `.text.middle` was unused so I removed it.
- `.text.italic` is replaced with `tw-italic`.
- `.text.normal` had exactly one use and it wasn't even needed.
- add a `muted` class to the link to `org_profile_avatar.tmpl`.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Fixes: https://github.com/go-gitea/gitea/issues/30384
On repo settings page, there id `repo_name` was used 5 times on the same
page, some in modal and such. I think we are better off just
auto-generating these IDs in the future so that labels link up with
their form element.
Ideally this id generation would be done in backend in a subtemplate,
but seeing that we already have similar JS patches for checkboxes, I
took the easy path for now.
I also checked that these `#repo_name` were not in use in JS and the
only case where this id appears in JS is on the migration page where
it's still there.
---------
Co-authored-by: Giteabot <teabot@gitea.io>
Fixes https://github.com/go-gitea/gitea/issues/30005. Regression from
https://github.com/go-gitea/gitea/pull/29945.
There was only once instance of `tw-content-center` before that PR, so I
just ran below command and reverted that one instance.
```sh
perl -p -i -e 's#tw-content-center#tw-items-center#g' web_src/js/**/* templates/**/* models/**/* tests/**/*
```
Fix for regressions introduced by #28805
Enabled projects on repos created before the PR weren't detected. Also,
the way projects mode was detected in settings didn't match the way it
was detected on permission check, which leads to confusion.
Co-authored-by: Giteabot <teabot@gitea.io>
With this option, it is possible to require a linear commit history with
the following benefits over the next best option `Rebase+fast-forward`:
The original commits continue existing, with the original signatures
continuing to stay valid instead of being rewritten, there is no merge
commit, and reverting commits becomes easier.
Closes#24906
