This is a implementation of #4277.
The core idea is that any activity (where activity is defined as anything that ends up in the `action` table) will be wrapped in an `ap.Note`, and sent to followers. Similarly, the inbox of local users now accepts such Notes. Additionally, there's now a "Feeds" tab on the user profile page, which displays the received notes.
# Preview
# How to Try?
The PR can be tried using a single Forgejo instance, but two distinct ones probably shows how it works better. For the sake of simplicity, lets try with a single instance. This is how to get started:
1. Enable federation
2. Subscribe one user to another (or to themselves):
```
curl -s -H "authorization: Bearer ${TOKEN}" -XPOST \
http://localhost:3000/api/v1/user/activitypub/follow \
--json '{"target": "http://localhost:3000/api/v1/activitypub/user-id/1"}'
```
This makes the first user follow themselves.
3. Create a repo, open an issue, or basically do anything that results in an activity recorded.
4. Visit `http://localhost:3000/{username}?tab=feed` to see the feed in action.
If you want to try with multiple instances, then it's very similar: you just change the `actor_id` to the IRI of the user you want to follow the first instance's user with, and then you can look at the feed tab of this user on the second instance, after you performed some activity on the first.
## Trying with Mastodon / GoToSocial
To try with Mastodon or GoToSocial, you will likely need to bring your Forgejo instance public, and behind https. Once your Forgejo instance is up, you can search for `@yourusername@forgejo.your.domain.example.com`, and simply follow your Forgejo account. Creating any activity will then happily federate to Mastodon & GoToSocial.
You can also copy & paste the Forge user's web profile URL (eg, `https://forgejo.your.domain.example.com/yourusername`) into your fedi client of choice, and it will discover the profile that way too.
# Testing
* test: https://codeberg.org/meissa/federation/src/branch/federated-user-activity-following/doc/user-activity-following/manual-test.md
* Proof of gts->forgejo: https://social.meissa-gmbh.de/@meissa/114499541149466596
* Proof of forgejo->gts: https://social.meissa-gmbh.de/@meissa/114505225265720094
## Architecture decisions
There are a number of ways user activity federation could be implemented. One way - which I explored first - is to wrap each activity, and send those, and let the client render it. The advantage of this would be that we'd be able to have references to other objects (comments, repos, etc). The disadvantage is that doing this requires making all of these things addressable, and that's a lot of work. Another disadvantage is that this requires every client to know how to display it.
Another way, chosen here, is to send a rendered HTML `ap.Note` instead, with an `AttributedTo` (`ap.Person`) property, which describes the activity that happened in a HTML note. This is much simpler to implement, and has the huge advantage that it is also easier to display. In fact, once we have http signatures, we should be able to federate user activity to Mastodon, too! (Though this also requires figuring out how Mastodon wants to follow a user...)
Since user activity federation is mostly cosmetic, as in, it's there for the user to see, rather than for programs to take actions based upon this activity, I believe that sending an `ap.Note` is preferable over a more machine-oriented approach.
## Limitations & TODO
### FederatedUser
We should be caching the Avatar in a similar way. For that, though, we also need to store the last activity of a federated user, so we can expire old avatars from the cache. The avatar refresh part will be covered by #4778.
### Notes
While sending out notes, the `AttributedTo` property is set to an `ap.Person`, based on the originating local user. This is currently unused. The idea is that once following is implemented properly (see above), we'll be able to link this to a FederatedUser (and thus to ExternalUser & User), which will allow us to display avatars and such, too.
### Display
The template used for displaying the received activities is currently incredibly simplistic. That's probably ok, it doesn't need to be fantastic.
### TODO
- [x] Fix the crashes on certain ops:
- [x] Issue/PR close & reopen
- [x] Figure out a better way to implement follows
- [x] Store the `AttributedTo` part of the note, too, the ID of it.
- [x] Make sure only those activities are sent out that need to be.
Currently, pretty much any activity is sent out, even private ones. We should be a bit smarter about that.
- [x] Make the ids used in the AP messages deterministic
The IDs used in the AP messages are currently UUIDs, and we do not store them, so all the IRIs are "invalid": the objects they refer to don't exist outside of the AP message itself. We should be able to reconstruct the Note objects and Create activities from their IDs.
- [x] Make it possible to follow Forgejo account from Mastodon and GtS
- [x] Mastodon without `AUTHORIZED_FETCH` works
- [x] GoToSocial can follow
- [x] Mastodon with `AUTHORIZED_FETCH` can follow
- ~~Create a cron job to refresh federated user avatars~~
- [x] Implement unfollowing
- [x] Add a `<link rel="alternate" type="application/activity+json" href="...">` to profile pages
This lets Mastodon & most other Fedi frontends discover the AP profile just by pasting a Forgejo user's web profile page into a search box, without having to know the corresponding AP actor URL
- [x] Make it easier to make a local user follow a remote AP actor
- ~~Rebase on top of #4778 by @realaravinth, once that is ready~~
- [x] Create an API endpoint to list the AP feed
- [x] Create a DB migration for the new stuff
- [x] Make swagger stuff happy
- [x] Clean up the commit history
- [x] ~~Tests~~ Opting for manual testing for now.
Co-authored-by: Michael Jerger <michael.jerger@meissa-gmbh.de>
Co-authored-by: famfo <famfo@famfo.xyz>
Co-authored-by: jerger <jerger@noreply.codeberg.org>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4767
Reviewed-by: jerger <jerger@noreply.codeberg.org>
Reviewed-by: elle <0xllx0@noreply.codeberg.org>
While `repo.OriginalURL` is supposed to be sanitized, with username and
passwords removed, it appears that is not always the case, and sometimes
we may encounter original URLs that aren't sanitized. While that is
possibly a historical artifact, we should still treat it with care.
As such, before displaying `repo.OriginalURL` as an info flash when
syncing a pull repository, sanitize the URL first, to be on the safe
side.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Since we have artifact fixtures now, some ids are in use. To avoid
reusing IDs, start them at 42, rather than 0. That's past the ids used
by the fixtures.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
- Adjust `PrepareArtifactsStorage` to use `require.NoError` instead of
`assert.NoError`
- Adjust `TestActionsArtifactDownload` to have the proper order of
`assert.Equal` arguments.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
This is a followup to gitea#31973, and removes the HTML tags for the
rest of the languages too.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
This adds a new configuration setting: `[quota.default].TOTAL`, which
will be used if no groups are configured for a particular user. The new
option makes it possible to entirely skip configuring quotas via the API
if all that one wants is a total size.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
An instance-wide actor is required for outgoing signed requests that are
done on behalf of the instance, rather than on behalf of other actors.
Such things include updating profile information, or fetching public
keys.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Mastodon with `AUTHORIZED_FETCH` enabled requires the `Host` header to
be signed too, add it to the default for `setting.Federation.GetHeaders`
and `setting.Federation.PostHeaders`.
For this to work, we need to sign the request later: not immediately
after `NewRequest`, but just before sending them out with `client.Do`.
Doing so also lets us use `setting.Federation.GetHeaders` (we were using
`.PostHeaders` even for GET requests before).
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
The previous commit laid out the foundation of the quota engine, this
one builds on top of it, and implements the actual enforcement.
Enforcement happens at the route decoration level, whenever possible. In
case of the API, when over quota, a 413 error is returned, with an
appropriate JSON payload. In case of web routes, a 413 HTML page is
rendered with similar information.
This implementation is for a **soft quota**: quota usage is checked
before an operation is to be performed, and the operation is *only*
denied if the user is already over quota. This makes it possible to go
over quota, but has the significant advantage of being practically
implementable within the current Forgejo architecture.
The goal of enforcement is to deny actions that can make the user go
over quota, and allow the rest. As such, deleting things should - in
almost all cases - be possible. A prime exemption is deleting files via
the web ui: that creates a new commit, which in turn increases repo
size, thus, is denied if the user is over quota.
Limitations
-----------
Because we generally work at a route decorator level, and rarely
look *into* the operation itself, `size:repos:public` and
`size:repos:private` are not enforced at this level, the engine enforces
against `size:repos:all`. This will be improved in the future.
AGit does not play very well with this system, because AGit PRs count
toward the repo they're opened against, while in the GitHub-style fork +
pull model, it counts against the fork. This too, can be improved in the
future.
There's very little done on the UI side to guard against going over
quota. What this patch implements, is enforcement, not prevention. The
UI will still let you *try* operations that *will* result in a denial.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
This is an implementation of a quota engine, and the API routes to
manage its settings. This does *not* contain any enforcement code: this
is just the bedrock, the engine itself.
The goal of the engine is to be flexible and future proof: to be nimble
enough to build on it further, without having to rewrite large parts of
it.
It might feel a little more complicated than necessary, because the goal
was to be able to support scenarios only very few Forgejo instances
need, scenarios the vast majority of mostly smaller instances simply do
not care about. The goal is to support both big and small, and for that,
we need a solid, flexible foundation.
There are thee big parts to the engine: counting quota use, setting
limits, and evaluating whether the usage is within the limits. Sounds
simple on paper, less so in practice!
Quota counting
==============
Quota is counted based on repo ownership, whenever possible, because
repo owners are in ultimate control over the resources they use: they
can delete repos, attachments, everything, even if they don't *own*
those themselves. They can clean up, and will always have the permission
and access required to do so. Would we count quota based on the owning
user, that could lead to situations where a user is unable to free up
space, because they uploaded a big attachment to a repo that has been
taken private since. It's both more fair, and much safer to count quota
against repo owners.
This means that if user A uploads an attachment to an issue opened
against organization O, that will count towards the quota of
organization O, rather than user A.
One's quota usage stats can be queried using the `/user/quota` API
endpoint. To figure out what's eating into it, the
`/user/repos?order_by=size`, `/user/quota/attachments`,
`/user/quota/artifacts`, and `/user/quota/packages` endpoints should be
consulted. There's also `/user/quota/check?subject=<...>` to check
whether the signed-in user is within a particular quota limit.
Quotas are counted based on sizes stored in the database.
Setting quota limits
====================
There are different "subjects" one can limit usage for. At this time,
only size-based limits are implemented, which are:
- `size:all`: As the name would imply, the total size of everything
Forgejo tracks.
- `size:repos:all`: The total size of all repositories (not including
LFS).
- `size:repos:public`: The total size of all public repositories (not
including LFS).
- `size:repos:private`: The total size of all private repositories (not
including LFS).
- `size:git:all`: The total size of all git data (including all
repositories, and LFS).
- `size:git:lfs`: The size of all git LFS data (either in private or
public repos).
- `size:assets:all`: The size of all assets tracked by Forgejo.
- `size:assets:attachments:all`: The size of all kinds of attachments
tracked by Forgejo.
- `size:assets:attachments:issues`: Size of all attachments attached to
issues, including issue comments.
- `size:assets:attachments:releases`: Size of all attachments attached
to releases. This does *not* include automatically generated archives.
- `size:assets:artifacts`: Size of all Action artifacts.
- `size:assets:packages:all`: Size of all Packages.
- `size:wiki`: Wiki size
Wiki size is currently not tracked, and the engine will always deem it
within quota.
These subjects are built into Rules, which set a limit on *all* subjects
within a rule. Thus, we can create a rule that says: "1Gb limit on all
release assets, all packages, and git LFS, combined". For a rule to
stand, the total sum of all subjects must be below the rule's limit.
Rules are in turn collected into groups. A group is just a name, and a
list of rules. For a group to stand, all of its rules must stand. Thus,
if we have a group with two rules, one that sets a combined 1Gb limit on
release assets, all packages, and git LFS, and another rule that sets a
256Mb limit on packages, if the user has 512Mb of packages, the group
will not stand, because the second rule deems it over quota. Similarly,
if the user has only 128Mb of packages, but 900Mb of release assets, the
group will not stand, because the combined size of packages and release
assets is over the 1Gb limit of the first rule.
Groups themselves are collected into Group Lists. A group list stands
when *any* of the groups within stand. This allows an administrator to
set conservative defaults, but then place select users into additional
groups that increase some aspect of their limits.
To top it off, it is possible to set the default quota groups a user
belongs to in `app.ini`. If there's no explicit assignment, the engine
will use the default groups. This makes it possible to avoid having to
assign each and every user a list of quota groups, and only those need
to be explicitly assigned who need a different set of groups than the
defaults.
If a user has any quota groups assigned to them, the default list will
not be considered for them.
The management APIs
===================
This commit contains the engine itself, its unit tests, and the quota
management APIs. It does not contain any enforcement.
The APIs are documented in-code, and in the swagger docs, and the
integration tests can serve as an example on how to use them.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Add an optional `order_by` parameter to the `user.ListMyRepos`
handler (which handles the `/api/v1/user/repos` route), allowing a user
to sort repos by name (the default), id, or size.
The latter will be useful later for figuring out which repos use most
space, which repos eat most into a user's quota.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
This adds a release note file for features cherry picked during the
2024-30 weekly gitea->forgejo cherry pick.
Thanks @earl-warren for the notes themselves!
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
The `/repos/{owner}/{repo}/issues/comments/{id}` API endpoint returns an
`assets` field, but the route handler did not load attachments, thus,
the field was never populated.
This patch fixes that, and adds a test to exercise it. The test fails
without the fix.
This addresses a bug discovered in Codeberg/Community#1607.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
When performing migrations, and need to remap external users to local
ones, when no local mapping is possible, map the external user to Ghost,
rather than the user who initiated the migration.
Mapping the external user to the migration initiator has the potential
of breaking assumptions elsewhere, like only having one review per pull
request per user. Mapping these migrated, locally unavailable users to
Ghost makes sure these - often hidden - assumptions do not break.
Fixes#3860.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
When installing Forgejo via the on-line installer, force
DisableRegistration to true, to discourage creating instances with open
registration. Because open registration requires constant vigil to fight
off spammers of all kinds, it is not a great default. It should be a
conscious decision. This change is made in an effort to make the choice
of running an instance with open registration a conscious choice, rather
than simply the default.
Partially addresses #3925.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Having an instance with open registration requires work, otherwise it
will be overrun by spammers of all kinds. Yet, the setting to disable
open registration on the installation page is hidden behind "optional
settings", a place hardly anyone ever looks.
To improve the situation, lift the setting out of that, and place it
more prominently, just above the update checker setting.
Partially addresses #3925.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Following gitea#28981, set `X-Forgejo-Sender` and `X-Forgejo-Recipient`
to the username of the respective users, rather than their display name.
The username is more appropriate for these headers, for filtering
purposes. The display name is already included in the From header.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
This adds a new test case to `TestCompareCodeExpand` to exercise the
case where we're viewing a PR's diff.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Previously, if no branch was explicitly specified for a workflow, it
defaulted to the default branch of the repo. This worked fine for
workflows that were triggered on push, but it prevented showing badges
for workflows that only run on tags, or on schedule - since they do not
run on a specific branch.
Thus, relax the conditions, and if no branch is specified, just return
the latest run of the given workflow. If one is specified, *then*
restrict it to said branch.
Fixes#3487.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
When expanding code diffs, the expansion should search for more context
in the commits repo, rather than in the repo in context, because the
commit may not be available in the base repo. For example, when
previewing a pull request, the commit is not in the target repo yet -
it's in the fork.
Fixes#3746.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
When rendering templates for packages, be more forgiving about missing
metadata. For some repository types - like maven - metadata is uploaded
separately. If that upload fails, or does not happen, there will be no
metadata.
In that case, Forgejo should handle it gracefully, and render as much of
the information as possible, without erroring out. Rendering without
metadata allows one to delete a partial package, while if we throw
errors, that becomes a whole lot harder.
This patch adjusts the generic metadata template, and also the maven
template. There may be more cases of the same problem lying around.
Fixes#3663.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Before explaining the fix itself, lets look at the `action` table, and
how it is populated. Data is only ever inserted into it via
`activities_model.NotifyWatchers`, which will:
- Insert a row for each activity with `UserID` set to the acting user's
ID - this is the original activity, and is always inserted if anything
is to be inserted at all.
- It will insert a copy of each activity with the `UserID` set to the
repo's owner, if the owner is an Organization, and isn't the acting
user.
- It will insert a copy of each activity for every watcher of the repo,
as long as the watcher in question has read permission to the repo
unit the activity is about.
This means that if a repository belongs to an organizations, for most
activities, it will have at least two rows in the table. For
repositories watched by people other than their owner, an additional row
for each watcher.
These are useful duplicates, because they record which activities are
relevant for a particular user. However, for cases where we wish to see
the activities that happen around a repository, without limiting the
results to a particular user, we're *not* interested in the duplicates
stored for the watchers and the org. We only need the originals.
And this is what this change does: it introduces an additional option to
`GetFeedsOptions`: `OnlyPerformedByActor`. When this option is set,
`activities.GetFeeds()` will only return the original activities, where
the user id and the acting user id are the same. As these are *always*
inserted, we're not missing out on any activities. We're just getting
rid of the duplicates. As this is an additional `AND` condition, it can
never introduce items that would not have been included in the result
set before, it can only reduce, not extend.
These duplicates were only affecting call sites where `RequestedRepo`
was set, but `RequestedUser` and `RequestedTeam` were not. Both of those
call sites were updated to set `OnlyPerformedByActor`. As a result,
repository RSS feeds, and the `/repos/{owner}/{repo}/activities/feeds`
API end points no longer return dupes, only the original activities.
Rather than hardcoding this behaviour into `GetFeeds()` itself, I chose
to implement it as an explicit option, for the sake of clarity.
FixesCodeberg/Community#684, and addresses gitea#20986.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
This fixes `initRepoPullRequestAllowMaintainerEdit()` to submit the form correctly (as a web form, rather than as JSON payload).
Fixes#3618, cherry picked from gitea#30854.
Co-Authored-By: wxiaoguang <wxiaoguang@gmail.com>
---
Manual testing steps:
- Open a PR against any repository, with the "Allow edits from maintainers" option checked.
- Open the developer console (`Ctrl-Shift-I` on Firefox), and look at the Network tab.
- Visit the PR, find the "Allow edits from maintainers" checkbox, and click it.
- See the developer console, and check that the response says the setting is false.
- Refresh the page *completely* (`Ctrl-Shift-R` on Firefox)
- Observe that the setting is off.
- Click the box again to enable it.
- See the developer console, and check that the response says the setting is true.
- Reload without cache again (`Ctrl-Shift-R` on Firefox)
- Observe that the setting is now on.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3675
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Co-committed-by: Gergely Nagy <forgejo@gergo.csillger.hu>
In `repo.RemoveDependency`, use `PostFormValue` instead of
`PostForm.Get`. The latter requires `ParseForm()` to be called prior,
and in this case, has no benefit over `PostFormValue` anyway (which
calls `ParseForm()` if necessary).
While this currently does not cause any issue as far as I can tell, it
feels like a bug lying in wait for the perfect opportunity. Lets squash
it before it can do harm.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Adjust the `anyHashPattern` to match URL query parameters too, and
adjust `fullHashPatternProcessor` accordingly.
Includes a test case, and an update to an existing one to account for
the new capture group.
Fixes#3548.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
To be able to easily test cases where the repository does not have any
code, where the git repo itself is completely uninitialized, lets
support a case where the `AutoInit` property is false.
For the sake of backwards compatibility, if the option is not set either
way, it will default to `true`.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
When subscribing or unsubscribing to/from an issue on the web ui, the
request was posted to a route handled by `repo.IssueWatch`. This
function used `ctx.Req.PostForm.Get()`, erroneously.
`request.PostForm` is *only* available if `request.ParseForm()` has been
called before it. The function in question did not do that. Under some
circumstances, something, somewhere did end up calling `ParseForm()`,
but not in every scenario.
Since we do not need to check for multiple values, the easiest fix here
is to use `ctx.Req.PostFormValue`, which will call `ParseForm()` if
necessary.
Fixes#3516.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
If `commitstatus_service.FindReposLastestCommitStatuses` receives no
repos in its params, short-circuit, and return early, without performing
any potentially expensive work.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
When a logged in user with no repositories visits their dashboard, it will
display a search box that lists their own repositories.
This is served by the `repo.SearchRepos` handler, which in turn calls
`commitstatus_service.FindReposLastestCommitStatuses()` with an empty
repo list.
That, in turn, will call `git_model.FindBranchesByRepoAndBranchName()`,
with an empty map. With no map, `FindBranchesByRepoAndBranchName()` ends
up querying the entire `branch` table, because no conditions were set
up.
Armed with a gazillion repo & commit shas, we return to
`FindReposLastestCommitStatuses`, and promptly call
`git_model.GetLatestCommitStatusForPairs`, which constructs a monstrous
query with so many placeholders that the database tells us to go
somewhere else, and flips us off. At least on instances the size of
Codeberg. On smaller instances, it will eventually return, and throw
away all the data, and return an empty set, having performed all this
for naught.
We fix this by short-circuiting `FindBranchesByRepoAndBranchName`, and
returning fast if our inputs are empty.
A test case is included.
Fixes#3521.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
When mentioning a user, the markup post-processor did not handle the
case where the mentioned user did not exist well: it tried to skip to
the next node, which in turn, ended up skipping the rest of the line.
To fix this, lets skip just the mentioned, but non-existing user, and
continue processing the current node from there.
Fixes#3535.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Gitea and Forgejo chose to implement wiki branch naming differently, but
Forgejo picked the Gitea migration anyway, resulting in an unused column
in the database, which wasn't part of the `Repository` struct either -
something warned about during startup, too.
Similarly, Forgejo chose not to implement User badges at all - but kept
the existing code for it -, and the `badge` table ended up with an
unused `slug` column due to a Gitea migration, and resulted in another
warning at startup.
To keep the database consistent with the code, and to get rid of these
warnings, lets introduce a new migration, which simply drops these
Gitea-specific columns from the database.
Fixes#3463.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
When converting a `repo_model.Repository` to `api.Repository`, copy the
`ObjectFormatName` field too.
Fixes#3458.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Add a new member to `DeclarativeRepoOptions`: `WikiBranch`. If
specified, create a Wiki with the given branch, and a single "Home"
page.
This will be used by an upcoming test.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Back in #2264, we made it possible to change the branch wikis use from
the hardcoded "master" branch to `[repository].DEFAULT_BRANCH`. However,
the API endpoints were not updated, and the "master" branch remained
hardcoded there.
This change fixes that, the API endpoints will now respect the
repository's `WikiBranch`.
Fixes#3391.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Lets introduce a new helper function,
`CreateDeclarativeRepoWithOptions`! This is almost the same as the
existing `CreateDeclarativeRepo` helper, but instead of taking a list of
random parameters the author thought of at the time of its introduction,
it takes a `DeclarativeRepoOptions` struct, with optional members.
This makes it easier to extend the function, as new members can be added
without breaking or having to update existing callsites, as long as the
newly added members default to compatible values.
`CreateDeclarativeRepo` is then reimplemented on top of the new
function. Callsites aren't updated yet, we can do that organically,
whenever touching code that uses the older function.
No new functionality is introduced just yet, this is merely a refactor.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
The WIP prefix toggling link on the sidebar only supported toggling
the *first* prefix specified in
`[repository.pullrequest].WORK_IN_PROGRESS_PREFIXES`. If the pull
request had a title with any other prefix, the first prefix listed in
the config was added (and then removed on toggling it off).
This little change makes all of the prefixes available for the
JavaScript function that does the toggling, and changes said function to
find the used prefix first, and toggle that.
When adding the prefix, it will still default to adding the first one
listed in the configuration, but it will happily remove any others if
those are present.
Fixes#3377.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
When searching for users, page the results by default, and respect the
default paging limits.
This makes queries like '/api/v1/users/search?limit=1' actually work.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
If `[email.incoming].USE_TLS` is set, but the port isn't, infer the
default from `.USE_TLS`: set the port to 993 if using tls, and to 143
otherwise. Explicitly setting a port overrides this.
Fixes#3357.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
The keys for setting the username and password for incoming and outgoing
mail are inconsisent: one uses `USERNAME` and `PASSWORD`, the other uses
`USER` and `PASSWD`.
To make things simpler, allow both to be configured by either, thus,
`[mailer].USERNAME` and `[mailer.PASSWORD]` will be aliases for `.USER`
and `.PASSWD`, and similarly, `[email.incoming].USER` and
`[email.incoming].PASSWD` will be aliases for `.USERNAME` and
`.PASSWORD`.
Fixes#3355.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
It is possible to change some repo settings (its visibility, and
template status) via `git push` options: `-o repo.private=true`, `-o
repo.template=true`.
Previously, there weren't sufficient permission checks on these, and
anyone who could `git push` to a repository - including via an AGit
workflow! - was able to change either of these settings. To guard
against this, the pre-receive hook will now check if either of these
options are present, and if so, will perform additional permission
checks to ensure that these can only be set by a repository owner or
an administrator. Additionally, changing these settings is disabled for
forks, even for the fork's owner.
There's still a case where the owner of a repository can change the
visibility of it, and it will not propagate to forks (it propagates to
forks when changing the visibility via the API), but that's an
inconsistency, not a security issue.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Signed-off-by: Earl Warren <contact@earl-warren.org>
When sending notification emails about a release, use a properly
formatted, RFC-compliant message id, rather than the release's HTML URL
wrapped in angle brackets (which would not be compliant).
Fixes#3105.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Rather than using an scp-style URI, use the same URL style for SSH
clones as for HTTP(S) ones. This is not only more consistent, but the
URL style allows one to specify a port, and makes it clear that it is an
SSH clone URL.
git itself favours the URL style, and mentions the scp-style in passing
only. Said style is prominently used by GitHub, and might be more
familiar for a lot of people, but other than familiarity, it has no
advantage over the URL style.
For the benefit of consistency, and flexibility, lets flip the default,
and make it the URL style. Instance admins who prefer to use the
scp-style, and are running SSH on its standard port, can change the
setting back to false.
This addresses #3193.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
When editing a user via the API, do not require setting `login_name` or
`source_id`: for local accounts, these do not matter. However, when
editing a non-local account, require *both*, as before.
Fixes#1861.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
This is a continuation of #2728, with a test case added.
Fixes#2633.
I kept @zareck 's commit as is, because I believe it is correct. We can't move the check to `owner.CanForkRepo()`, because `owner` is the future owner of the forked repo, and may be an organization. We need to check the admin permission of the `doer`, like in the case of repository creation.
I verified that the test fails without the `ForkRepository` change, and passes with it.
Co-authored-by: Cassio Zareck <cassiomilczareck@gmail.com>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3277
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Co-committed-by: Gergely Nagy <forgejo@gergo.csillger.hu>
The global wiki editability can be set via the web UI, this patch makes
it possible to set the same thing via the API too. This is accomplished
by adjusting the GET and PATCH handlers of the
`/api/v1/repos/{owner}/{repo}` route.
The first will include the property when checking the repo's settings,
the second allows a repo admin to change the setting too.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
When visiting a repos `/settings/units` page, highlight the active tab
properly: "Add more..." if the tab is displayed, or "Settings"
otherwise.
Fixes#3188.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
While users can edit their own pronouns, the admin UI enables an admin
to edit *any* user setting. As such, pronouns should be editable here,
too.
For the sake of simplicity, the input here is a simple text input field,
rather than a dropdown.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
When converting from a `user_model.User` to `api.User` or
`api.UserSettings`, convert the `Pronouns` field too.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Move the signed tag verification line above the release notes, don't
disable the bottom margin, and make sure the verification line's box is
properly rounded like other boxes.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
This makes signed tags show a badge in the tag list similar to signed
commits in the commit list, and a more verbose block when viewing a
single tag. Works for both GPG and SSH signed tags.
Fixes#1316.
Work sponsored by @glts.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
This is, in large part, a refactoring: we rename `CommitVerification` to
`ObjectVerification`, and adjust `ParseObjectWithSignature` (previously
`ParseCommitWithSignature`) to work on an object, rather than a commit.
This in turn, lets us implement `ParseTagWithSignature` on top of it, so
commit & tag signature verification will share most of the code.
Work sponsored by @glts.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
The recent refactor imported from Gitea made the Fork counter/button in
the repo header appear as icon only on mobile, but left the Star & Watch
buttons unchanged, so they appeared with text. That resulted in the
mobile view looking a bit awkward, with half the widgets (rss & fork) as
icon-only, while the other half (star & watch) with both icon and text.
This changes the other two in the same way: to appear without text on
mobile.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
`CommitGPGSignature` was originally made to store information about a
commit's GPG signature. Nowadays, it is used to store information about
SSH signatures too, and not just commit signatures, but tag signatures
too.
As such, rename it to `ObjectSignature`, because that describes what it
does a whole lot better.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Because the `git` module did not recognize SSH signed tags, those
signatures ended up in the `notes` column of the `release` table. While
future signatures will not end up there, Forgejo should clean up the old
ones.
This migration does just that: finds all releases that have an SSH
signature, and removes those signatures, preserving the rest of the
note (if any).
While this may seem like an expensive operation, it's only done once,
and even on the largest known Forgejo instance as of this
writing (Codeberg), the number of affected rows are just over a hundred,
a tiny amount all things considered.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Just like commits, tags can be signed with either an OpenPGP, or with an
SSH key. While the latter is supported already, SSH-signed tags have not
been. This patch teaches the git module to recognize and handle
SSH-signed tags too.
This will stop the signatures appearing in release notes, but are
currently unused otherwise.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Adjust some CSS so that callout/attention icons line up better with the
text of the attention header.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
The previous (cherry picked) commit changed a translation key, from
`repo.pulls.no_results` to `common.no_results_found`. This would break
existing translations, and will have to be handled differently, if at
all.
This changes the affected code to continue using the old key.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
This removes some more dead code from the markup sanitizer:
- Allowing unlabelled labels is no longer neccessary as of
41e8b834af.
- Allowing `style` attributes on `span` and `p` are no longer necessary,
`bluemonday` allows them by default now.
Selectively cherry picked from commit 66902d89e567ab1ae6dfb828636999c61ff0149e.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
The alert/callout blocks rendering has been changed in the previous few
commits, this adapts the test case that verifies them to the updated
output.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Following up on the previous commit, change the GitHub Legacy callout
renderer to render the same as the refactored modern renderer.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
The function isn't used anywhere, it's dead code. Remove it.
Partially cherry picked from commit 46c3f3b9e81e25c3ed08ba6c5bfeb8802b3ba1fd.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Repositories displaying an "Add more..." tab on the header is a neat way
to let people discover they can enable more units. However, displaying
it all the time for repository owners, even when they deliberately do
not want to enable more units gets noisy very fast.
As such, this patch introduces a new setting which lets people disable
this hint under the appearance settings.
Fixes#2378.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
shields.io uses dashes to separate parts of the badge it needs to
return. If our label or text parts contain dashes, we need to encode
those for shields.io to recognise what we want it to do, and to have the
correct text on the badge, too.
Fortunately, this is as simple as replacing all dashes with double
dashes in both the label and the text parts. We do not need to do the
same for the color, because that part is not user controlled.
This fixes the badges for cases when a workflow name includes dashes, or
when a release's tag name does.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
A previous commit (via gitea#29638) changed the `.repository .data-table
.tr` CSS rule to forcibly override the background to `none`. This, in
turn, disabled the even-odd row coloring.
Doing so should be a preference of the theme used, and should not be
enforced by the core CSS rules. This patch removes the override.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
The `reloadParam` function already calls `context.UserAssignmentWeb`
with the same parameters, there's no need to do it again.
Change cherry picked from gitea#29751.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
This partially reverts c41b2c73ef: for the
sake of consistency, the title of a release should always be a link,
whether it's a tag-only release or not.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Update the `TestTagViewWithoutRelease` test case with another assert:
one that checks that the release title is properly displayed.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
In #2445, I lifted out the fork button into its own template, but did
not update it properly. This resulted in the fork button's counter not
displaying, and pointing to the wrong place too.
This patch updates the template to account for it moving to a separate
file, and also adds test cases to verify the button is display as it
should be.
Fixes#2494.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
