- The `<title>` element that lives inside the `<head>` element is an important element that gives browsers and search engine crawlers the title of the webpage, hence the element name. It's therefor important that this title is accurate.
- Currently there are three issues with titles on repositories. It doesn't use the `FullName` and instead only uses the repository name, this doesn't distinguish which user or organisation the repository is on. It doesn't show the full treepath in the title when visiting an file inside a directory and instead only uses the latest path in treepath. It can show the repository name twice if the `.Title` variable also included the repository name such as on the repository homepage.
- Use the repository's fullname (which include which user the repository is on) instead of just their name.
- Display the repository's fullname if it isn't already in `.Title`.
- Use the full treepath in the repository code view instead of just the
last path.
- Adds integration tests.
- Adds a new repository (`repo59`) that has 3 depths for folders, which
wasn't in any other fixture repository yet, so the full treepath for
could be properly tested.
- Resolves https://codeberg.org/forgejo/forgejo/issues/1276
(cherry picked from commit ff9a6a2cda)
(cherry picked from commit 76dffc8621)
(cherry picked from commit ff0615b9d0)
(cherry picked from commit 8712eaa394)
(cherry picked from commit 0c11587582)
(cherry picked from commit 3cbd9fb792)
Conflicts:
tests/integration/repo_test.go
https://codeberg.org/forgejo/forgejo/pulls/1512
(cherry picked from commit fbfdba8ae9)
Conflicts:
models/fixtures/release.yml
https://codeberg.org/forgejo/forgejo/pulls/1550
(cherry picked from commit 8b2bf0534c)
(cherry picked from commit d706d9e222)
- Resolves#271
- Ensure that the adminstrator password is at least `MIN_PASSWORD_LENGTH`.
(cherry picked from commit 28cb04c3f5)
(cherry picked from commit 95371ebd92)
(cherry picked from commit a134288ab6)
(cherry picked from commit 4202f052cb)
(cherry picked from commit 510b7467d3)
(cherry picked from commit f3a6e1f121)
(cherry picked from commit f340508819)
(cherry picked from commit b891bb176d)
(cherry picked from commit 1a1bfc38cc)
(cherry picked from commit 083d5aefed)
(cherry picked from commit 4586096be9)
(cherry picked from commit 039fa20cc8)
(cherry picked from commit 3ec9cb5f59)
(cherry picked from commit 00be0eee37)
(cherry picked from commit a156603002)
(cherry picked from commit 4d305e7774)
This field adds the possibility to set the update date when modifying
an issue through the API.
A 'NoAutoDate' in-memory field is added in the Issue struct.
If the update_at field is set, NoAutoDate is set to true and the
Issue's UpdatedUnix field is filled.
That information is passed down to the functions that actually updates
the database, which have been modified to not auto update dates if
requested.
A guard is added to the 'EditIssue' API call, to checks that the
udpate_at date is between the issue's creation date and the current
date (to avoid 'malicious' changes). It also limits the new feature
to project's owners and admins.
(cherry picked from commit c524d33402)
Add a SetIssueUpdateDate() function in services/issue.go
That function is used by some API calls to set the NoAutoDate and
UpdatedUnix fields of an Issue if an updated_at date is provided.
(cherry picked from commit f061caa655)
Add an updated_at field to the API calls related to Issue's Labels.
The update date is applied to the issue's comment created to inform
about the modification of the issue's labels.
(cherry picked from commit ea36cf80f5)
Add an updated_at field to the API call for issue's attachment creation
The update date is applied to the issue's comment created to inform
about the modification of the issue's content, and is set as the
asset creation date.
(cherry picked from commit 96150971ca)
Checking Issue changes, with and without providing an updated_at date
Those unit tests are added:
- TestAPIEditIssueWithAutoDate
- TestAPIEditIssueWithNoAutoDate
- TestAPIAddIssueLabelsWithAutoDate
- TestAPIAddIssueLabelsWithNoAutoDate
- TestAPICreateIssueAttachmentWithAutoDate
- TestAPICreateIssueAttachmentWithNoAutoDate
(cherry picked from commit 4926a5d7a2)
Add an updated_at field to the API call for issue's comment creation
The update date is used as the comment creation date, and is applied to
the issue as the update creation date.
(cherry picked from commit 76c8faecdc)
Add an updated_at field to the API call for issue's comment edition
The update date is used as the comment update date, and is applied to
the issue as an update date.
(cherry picked from commit cf787ad7fd)
Add an updated_at field to the API call for comment's attachment creation
The update date is applied to the comment, and is set as the asset
creation date.
(cherry picked from commit 1e4ff424d3)
Checking Comment changes, with and without providing an updated_at date
Those unit tests are added:
- TestAPICreateCommentWithAutoDate
- TestAPICreateCommentWithNoAutoDate
- TestAPIEditCommentWithAutoDate
- TestAPIEditCommentWithNoAutoDate
- TestAPICreateCommentAttachmentWithAutoDate
- TestAPICreateCommentAttachmentWithNoAutoDate
(cherry picked from commit da932152f1)
Pettier code to set the update time of comments
Now uses sess.AllCols().NoAutoToime().SetExpr("updated_unix", ...)
XORM is smart enough to compose one single SQL UPDATE which all
columns + updated_unix.
(cherry picked from commit 1f6a42808d)
Issue edition: Keep the max of the milestone and issue update dates.
When editing an issue via the API, an updated_at date can be provided.
If the EditIssue call changes the issue's milestone, the milestone's
update date is to be changed accordingly, but only with a greater
value.
This ensures that a milestone's update date is the max of all issue's
update dates.
(cherry picked from commit 8f22ea182e)
Rewrite the 'AutoDate' tests using subtests
Also add a test to check the permissions to set a date, and a test
to check update dates on milestones.
The tests related to 'AutoDate' are:
- TestAPIEditIssueAutoDate
- TestAPIAddIssueLabelsAutoDate
- TestAPIEditIssueMilestoneAutoDate
- TestAPICreateIssueAttachmentAutoDate
- TestAPICreateCommentAutoDate
- TestAPIEditCommentWithDate
- TestAPICreateCommentAttachmentAutoDate
(cherry picked from commit 961fd13c55)
(cherry picked from commit d52f4eea44)
(cherry picked from commit 3540ea2a43)
Conflicts:
services/issue/issue.go
https://codeberg.org/forgejo/forgejo/pulls/1415
(cherry picked from commit 56720ade00)
Conflicts:
routers/api/v1/repo/issue_label.go
https://codeberg.org/forgejo/forgejo/pulls/1462
(cherry picked from commit 47c78927d6)
(cherry picked from commit 2030f3b965)
(cherry picked from commit f02aeb7698)
(cherry picked from commit 2e43e49961)
- Currently the confirmation for dangerous actions such as transferring
the repository or deleting it only requires the user to ~~copy paste~~
type the repository name.
- This can be problematic when the user has a fork or another repository
with the same name as an organization's repository, and the confirmation
doesn't make clear that it could be deleting the wrong repository. While
it's mentioned in the dialog, it's better to be on the safe side and
also add the owner's name to be an element that has to be typed for
these dangerous actions.
- Added integration tests.
(cherry picked from commit bf679b24dd)
(cherry picked from commit 1963085dd9)
(cherry picked from commit fb94095d19)
(cherry picked from commit e1d1e46afe)
(cherry picked from commit 20b5669269)
(cherry picked from commit 1574643a6a)
Update semantic version according to specification
(cherry picked from commit 22510f4130)
Mise à jour de 'Makefile'
(cherry picked from commit c3d85d8409)
(cherry picked from commit 5ea2309851)
(cherry picked from commit ec5217b9d1)
(cherry picked from commit 14f08e364b)
(cherry picked from commit b4465c67b8)
[API] [SEMVER] replace number with version
(cherry picked from commit fba48e6497)
(cherry picked from commit 532ec5d878)
[API] [SEMVER] [v1.20] less is replaced by css
(cherry picked from commit 01ca3a4f42)
(cherry picked from commit 1d928c3ab2)
(cherry picked from commit a39dc804cd)
Conflicts:
webpack.config.js
(cherry picked from commit adc68578b3)
(cherry picked from commit 9b8d98475f)
(cherry picked from commit 2516103974)
(cherry picked from commit 18e6287963)
(cherry picked from commit e9694e67ab)
(cherry picked from commit a9763edaf0)
(cherry picked from commit e2b550f4fb)
(cherry picked from commit 2edac36701)
[API] Forgejo API /api/forgejo/v1 (squash)
Update semver as v1.20 is entering release candidate mode
(cherry picked from commit 4995098ec3)
(cherry picked from commit 578ccfdd27)
(cherry picked from commit 1bf6ac0952)
(cherry picked from commit 2fe16b2bfe)
(cherry picked from commit 7cd9d027ee)
(cherry picked from commit eaed4be2ae)
(cherry picked from commit cc94f3115f)
(cherry picked from commit d7a77e35cc)
(cherry picked from commit cd8eb68ab7)
(cherry picked from commit 68487ac95f)
(cherry picked from commit 616dceb565)
(cherry picked from commit 545fe5975b)
(cherry picked from commit c042cf8eda)
(cherry picked from commit ae5e5a7468)
(cherry picked from commit 8034ef5fa2)
(cherry picked from commit aaf0293034)
(cherry picked from commit daafa8ce58)
(cherry picked from commit 7ca3681d3e)
Backport #27446 by @sryze
storageHandler() is written as a middleware but is used as an endpoint
handler, and thus `next` is actually `nil`, which causes a null pointer
dereference when a request URL does not match the pattern (where it
calls `next.ServerHTTP()`).
Example CURL command to trigger the panic:
```
curl -I "http://yourhost/gitea//avatars/a"
```
Fixes#27409
---
Note: the diff looks big but it's actually a small change - all I did
was to remove the outer closure (and one level of indentation) ~and
removed the HTTP method and pattern checks as they seem redundant
because go-chi already does those checks~. You might want to check "Hide
whitespace" when reviewing it.
Alternative solution (a bit simpler): append `, misc.DummyOK` to the
route declarations that utilize `storageHandler()` - this makes it
return an empty response when the URL is invalid. I've tested this one
and it works too. Or maybe it would be better to return a 400 error in
that case (?)
Co-authored-by: Sergey Zolotarev <sryze@outlook.com>
Backport #27000 by @wxiaoguang
This PR reduces the complexity of the system setting system.
It only needs one line to introduce a new option, and the option can be
used anywhere out-of-box.
It is still high-performant (and more performant) because the config
values are cached in the config system.
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Backport #27115 by @puni9869
Followup https://github.com/go-gitea/gitea/pull/26820
## Archived labels UI for issue filter and issue filter actions for
issues/pull request pages.
Changed:
* Enhanced the Issue filter and Issue filter actions UI page to
seamlessly incorporate a list of archived labels.
* Pagination functionality is same as before. If archived label checkbox
is checked then we are adding a query string`archived=true` in the url
to save the state of page.
* Issue filter actions menu is separated into different template.
* Adding the archived flag in issue url labels.
* Pull Request page is also work the same.
Outsourced:
* Defer the implementation of specialized handling for archived labels
to upcoming pull requests. This step will be undertaken subsequent to
the successful merge of this pull request.
Screenshots
### Issue page
<img width="1360" alt="image"
src="https://github.com/go-gitea/gitea/assets/80308335/d7efb2ef-5b2b-449d-83f0-d430a32ec432">
### Issue page with label filter on archived label checkbox when not
checked --> No archived label is there in list
<img width="1249" alt="image"
src="https://github.com/go-gitea/gitea/assets/80308335/ceea68ef-91f2-4693-910f-2e25e236bfc9">
### Issue page with label filter on archived label checkbox when checked
--> Show archived label in the list.
<img width="710" alt="image"
src="https://github.com/go-gitea/gitea/assets/80308335/2414d26b-2079-4c3c-bd9e-f2f5411bcabf">
### Issue page with label filter on issue action menu on archived label
checkbox when checked --> Show archived label in the list.
<img width="409" alt="image"
src="https://github.com/go-gitea/gitea/assets/80308335/259cac87-3e21-4778-99a2-a6a0b8c81178">
### Applied the archived=true in Issue labels when archived checkbox is
checked.
<img width="984" alt="image"
src="https://github.com/go-gitea/gitea/assets/80308335/657ce3db-c0ae-402e-b12d-3b580d3c2ed0">
---
Part of https://github.com/go-gitea/gitea/issues/25237
Signed-off-by: puni9869 <punitinani1@hotmail.com>
Co-authored-by: puni9869 <80308335+puni9869@users.noreply.github.com>
Co-authored-by: delvh <dev.lh@web.de>
Backport #26803 by @n0toose
This change introduces some fixes for my original PR
(https://github.com/go-gitea/gitea/pull/26214) and introduces some
additional tests so that such a regression does not happen again in the
future.
Co-authored-by: Panagiotis "Ivory" Vasilopoulos <git@n0toose.net>
Backport #27265 by @JakobDev
Part of #27065
This PR touches functions used in templates. As templates are not static
typed, errors are harder to find, but I hope I catch it all. I think
some tests from other persons do not hurt.
Co-authored-by: JakobDev <jakobdev@gmx.de>
Backport #27143 by @lunny
Partially Fix#25041
This PR redefined the meaning of column `is_active` in table
`action_runner_token`.
Before this PR, `is_active` means whether it has been used by any
runner. If it's true, other runner cannot use it to register again.
In this PR, `is_active` means whether it's validated to be used to
register runner. And if it's true, then it can be used to register
runners until it become false. When creating a new `is_active` register
token, any previous tokens will be set `is_active` to false.
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Backport #27141 by @silverwind
Fixes https://github.com/go-gitea/gitea/issues/27136.
This does the following for Monaco's EOL setting:
1. Use editorconfig setting if present
2. Use the file's dominant line ending as detected by monaco, which uses
LF for empty file
Co-authored-by: silverwind <me@silverwind.io>
Beginning since 2af30f715e, Gitea has a
500 error when visiting a user profile with `?tab=overview` in the URL
when the user doesn't have a `.profile/README.md`, because the backend
code assumes that if the tab is overview a profile repository must
exist, and checks that the repository is nil aren't done.
In this PR I treat `?tab=overview` the same as if no tab is set in the
URL, which corrects this behaviour- Now, when visiting `?tab=overview`,
if `.profile/README.md` exists on that user's profile it'll show that as
it should, otherwise it'll show the repositories tab.
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
- Use the correct total amount for pagination. Thereby correctly show
the pagination bare when there's more than one page of
followers/followings.
Refs: https://codeberg.org/forgejo/forgejo/pulls/1477
(cherry picked from commit c1a136318b)
Co-authored-by: Gusted <postmaster@gusted.xyz>
Closes#26329
This PR adds the ability to ignore revisions specified in the
`.git-blame-ignore-revs` file in the root of the repository.
The banner is displayed in this case. I intentionally did not add a UI
way to bypass the ignore file (same behaviour as Github) but you can add
`?bypass-blame-ignore=true` to the url manually.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
This PR adds a new field `RemoteAddress` to both mirror types which
contains the sanitized remote address for easier (database) access to
that information. Will be used in the audit PR if merged.
Part of #27065
This reduces the usage of `db.DefaultContext`. I think I've got enough
files for the first PR. When this is merged, I will continue working on
this.
Considering how many files this PR affect, I hope it won't take to long
to merge, so I don't end up in the merge conflict hell.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Fix#26723
Add `ChangeDefaultBranch` to the `notifier` interface and implement it
in `indexerNotifier`. So when changing the default branch,
`indexerNotifier` sends a message to the `indexer queue` to update the
index.
---------
Co-authored-by: techknowlogick <matti@mdranta.net>
Most middleware throw a 404 in case something is not found e.g. a Repo
that is not existing. But most API endpoints don't include the 404
response in their documentation. This PR changes this.
Unfortunately, when a system setting hasn't been stored in the database,
it cannot be cached.
Meanwhile, this PR also uses context cache for push email avatar display
which should avoid to read user table via email address again and again.
According to my local test, this should reduce dashboard elapsed time
from 150ms -> 80ms .
