A remote user (UserTypeRemoteUser) is a placeholder that can be
promoted to a regular user (UserTypeIndividual). It represents users
that exist somewhere else. Although the UserTypeRemoteUser already
exists in Forgejo, it is neither used or documented.
A new login type / source (Remote) is introduced and set to be the login type
of remote users.
Type UserTypeRemoteUser
LogingType Remote
The association between a remote user and its counterpart in another
environment (for instance another forge) is via the OAuth2 login
source:
LoginName set to the unique identifier relative to the login source
LoginSource set to the identifier of the remote source
For instance when migrating from GitLab.com, a user can be created as
if it was authenticated using GitLab.com as an OAuth2 authentication
source.
When a user authenticates to Forejo from the same authentication
source and the identifier match, the remote user is promoted to a
regular user. For instance if 43 is the ID of the GitLab.com OAuth2
login source, 88 is the ID of the Remote loging source, and 48323
is the identifier of the foo user:
Type UserTypeRemoteUser
LogingType Remote
LoginName 48323
LoginSource 88
Email (empty)
Name foo
Will be promoted to the following when the user foo authenticates to
the Forgejo instance using GitLab.com as an OAuth2 provider. All users
with a LoginType of Remote and a LoginName of 48323 are examined. If
the LoginSource has a provider name that matches the provider name of
GitLab.com (usually just "gitlab"), it is a match and can be promoted.
The email is obtained via the OAuth2 provider and the user set to:
Type UserTypeIndividual
LogingType OAuth2
LoginName 48323
LoginSource 43
Email foo@example.com
Name foo
Note: the Remote login source is an indirection to the actual login
source, i.e. the provider string my be set to a login source that does
not exist yet.
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>
This adds a new options to releases to hide the links to the automatically generated archives. This is useful, when the automatically generated Archives are broken e.g. because of Submodules.
Note:
This juts hides the Archives from the UI. Users can still download 5the Archive if they know t correct URL.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3139
Reviewed-by: Otto <otto@codeberg.org>
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: JakobDev <jakobdev@gmx.de>
Co-committed-by: JakobDev <jakobdev@gmx.de>
Add some logic in `convert.ToBranchProtection` to return only the names
associated with readAccess instead of returning all names. This will
ensure consistency in behavior between the frontend and backend.
Fixes: #27694
---------
Co-authored-by: techknowlogick <techknowlogick@gitea.com>
Co-authored-by: wenzhuo.zhang <wenzhuo.zhang@geely.com>
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit 02e183bf3fa502b7cef76e8dcdbf01b85ce641f0)
- Add new `Compare` struct to represent comparison between two commits
- Introduce new API endpoint `/compare/*` to get commit comparison
information
- Create new file `repo_compare.go` with the `Compare` struct definition
- Add new file `compare.go` in `routers/api/v1/repo` to handle
comparison logic
- Add new file `compare.go` in `routers/common` to define `CompareInfo`
struct
- Refactor `ParseCompareInfo` function to use `common.CompareInfo`
struct
- Update Swagger documentation to include the new API endpoint for
commit comparison
- Remove duplicate `CompareInfo` struct from
`routers/web/repo/compare.go`
- Adjust base path in Swagger template to be relative (`/api/v1`)
GitHub API
https://docs.github.com/en/rest/commits/commits?apiVersion=2022-11-28#compare-two-commits
---------
Signed-off-by: Bo-Yi Wu <appleboy.tw@gmail.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
(cherry picked from commit c70e442ce4b99e2a1f1bf216afcfa1ad78d1925a)
Conflicts:
- routers/api/v1/swagger/repo.go
Conflict resolved by manually adding the lines from the Gitea
PR.
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 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>
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>
Fix#30378
(cherry picked from commit 0fe9f93eb4c94d55e43b18b9c3cc6d513a34c0b5)
Conflicts:
- models/organization/org.go
- services/repository/delete.go
- services/user/delete.go
In all three cases, conflicts were resolved by manually adding
the lines added by the Gitea patch, keeping the Forgejo code
surrounding them.
`log.Xxx("%v")` is not ideal, this PR adds necessary context messages.
Remove some unnecessary logs.
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit 83f83019ef3471b847a300f0821499b3896ec987)
Conflicts:
- modules/util/util.go
Conflict resolved by picking `util.Iif` from 654cfd1dfbd3f3f1d94addee50b6fe2b018a49c3
Fix https://github.com/go-gitea/gitea/issues/30428
---
Conflict resolution: trivial and move test to own subtest run directly
after `Normal`.
(cherrypicked commit 9466fec879f4f2c88c7c1e7a5cffba319282ab66)
Related to #2773
Related to Refactor URL detection [gitea#29960](https://github.com/go-gitea/gitea/pull/29960)
Related to Refactor external URL detection [gitea#29973](https://github.com/go-gitea/gitea/pull/29973)
I added a bunch of tests to `httplib.TestIsRiskyRedirectURL` and some cases should be better handled (however it is not an easy task).
I also ported the removal of `utils.IsExternalURL`, since it prevents duplicated (subtle) code.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3167
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: oliverpool <git@olivier.pfad.fr>
Co-committed-by: oliverpool <git@olivier.pfad.fr>
* Split TestPullRequest out of AddTestPullRequestTask
* A Created field is added to the Issue table
* The Created field is set to the time (with nano resolution) on creation
* Record the nano time repo_module.PushUpdateOptions is created by the hook
* The decision to update a pull request created before a commit was
pushed is based on the time (with nano resolution) the git hook
was run and the Created field
It ensures the following happens:
* commit C is pushed
* the git hook queues AddTestPullRequestTask for processing and returns with success
* TestPullRequest is not called yet
* a pull request P with commit C as the head is created
* TestPullRequest runs and ignores P because it was created after the commit was received
When the "created" column is NULL, no verification is done, pull
requests that were created before the column was created in the
database cannot be newer than the latest call to a git hook.
Fixes: https://codeberg.org/forgejo/forgejo/issues/2009
This PR do some performance optimzations.
- [x] Add `index` for the column `comment_id` of `Attachment` table to
accelerate query from the database.
- [x] Remove unnecessary database queries when viewing issues. Before
some conditions which id = 0 will be sent to the database
- [x] Remove duplicated load posters
- [x] Batch loading attachements, isread of comments on viewing issue
---------
Co-authored-by: Zettat123 <zettat123@gmail.com>
Conflicts:
models/issues/comment_code.go: function was renamed in Forgejo
models/migrations/migrations.go: migration already ported
- Adds setting `EXTERNAL_USER_DISABLE_FEATURES` to disable any supported
user features when login type is not plain
- In general, this is necessary for SSO implementations to avoid
inconsistencies between the external account management and the linked
account
- Adds helper functions to encourage correct use
(cherry picked from commit 59d4aadba5c15d02f3b9f0e61abb7476870c20a5)
Conflicts:
- docs/content/administration/config-cheat-sheet.en-us.md
Removed.
- modules/setting/admin.go
Trivial resolution: pick the newly added struct member.
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>
- Use the correct template that was given when there's an error in
retrieving which git identity should be used.
- Remove the error from the exception list.
This is a squashed result of conflict resolution for the following commits from Gitea:
- 36de5b299b
- 9a93b1816e
- 712e19fa6f
- 83850cc479
It is lacking CSS rule for archived labels, though.
Changes in this commit are authored by:
- 6543
- delvh
- silverwind
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>
Resolves#29965.
---
Manually tested this by:
- Following the
[installation](https://docs.gitea.com/next/installation/install-with-docker#basics)
guide (but built a local Docker image instead)
- Creating 2 users, one who is the `Owner` of a newly-created repository
and the other a `Collaborator`
- Had the `Collaborator` create a PR that the `Owner` reviews
- `Collaborator` resolves conversation and `Owner` merges PR
And with this change we see that we can no longer see re-request review
button for the `Owner`:
<img width="1351" alt="Screenshot 2024-03-25 at 12 39 18 AM"
src="https://github.com/go-gitea/gitea/assets/60799661/bcd9c579-3cf7-474f-a51e-b436fe1a39a4">
(cherry picked from commit 242b331260925e604150346e61329097d5731e77)
On creation of an empty project (no template) a default board will be
created instead of falling back to the uneditable pseudo-board.
Every project now has to have exactly one default boards. As a
consequence, you cannot unset a board as default, instead you have to
set another board as default. Existing projects will be modified using a
cron job, additionally this check will run every midnight by default.
Deleting the default board is not allowed, you have to set another board
as default to do it.
Fixes#29873Fixes#14679 along the way
Fixes#29853
Co-authored-by: delvh <dev.lh@web.de>
(cherry picked from commit e5160185ed65fd1c2bcb2fc7dc7e0b5514ddb299)
Conflicts:
options/locale/locale_en-US.ini
trivial conflict because Forgejo strings do not have
surrounding double quotes
Now, the chars `=:;()[]{}~!@#$%^ &` are possible as well
Fixes#30134
---------
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
(cherry picked from commit 1ad48f781eb0681561b083b49dfeff84ba51f2fe)
- Currently protected branch rules do not apply to admins, however in
some cases (like in the case of Forgejo project) you might also want to
apply these rules to admins to avoid accidental merges.
- Add new option to configure this on a per-rule basis.
- Adds integration tests.
- Resolves#65
