Fixes https://github.com/go-gitea/gitea/issues/3476

• [x] Move Issues between Boards
• [x] add Project to current Issue
• [x] view project
• [x] create a project
• [x] create Issue during viewing project
• [x] select project during create Issue
• [x] add Board to an existing Project
• [x] delete Board from a project
• [x] rename Board title
• [x] Individual boards
• [x] Organization boards
• [x] Repository boards

Definitely another PR:

• [x] Location of cards in the project board. Right now, cards location in a board cannot be persisted - i.e move card X above card Y in the same board.

@rudineirk UI suggestion ( from https://github.com/go-gitea/gitea/issues/3476#issuecomment-416950682 ) was used.

This PR replaces all use of emojify.js and adds unicode emoji support to various areas of gitea.

This works in a few ways:

First it adds emoji parsing support into gitea itself. This allows us to

• Render emojis from valid alias (:smile:)
• Detect unicode emojis and let us put them in their own class with proper aria-labels and styling
• Easily allow for custom "emoji"
• Support all emoji rendering and features without javascript
• Uses plain unicode and lets the system render in appropriate emoji font
• Doesn't leave us relying on external sources for updates/fixes/features

That same list of emoji is also used to create a json file which replaces the part of emojify.js that populates the emoji search tribute.

For custom "emoji" it uses a pretty simple scheme of just looking for /emojis/img/name.png where name is something a user has put in the "allowed reactions" setting we already have. The gitea reaction that was previously hard coded into a forked copy of emojify.js is included and works as a custom reaction under this method.

The emoji data sourced here is from https://github.com/github/gemoji which is the gem library Github uses for their emoji rendering (and a data source for other sites). So we should be able to easily render any emoji and :alias: that Github can, removing any errors from migrated content. They also update it as well, so we can sync when there are new unicode emoji lists released.

I've included a slimmed down and slightly modified forked copy of https://github.com/knq/emoji to make up our own emoji module. The code is pretty straight forward and again allows us to have a lot of flexibility in what happens.

I had seen a few comments about performance in some of the other threads if we render this ourselves, but there doesn't seem to be any issue here. In a test it can parse, convert, and render 1,000 emojis inside of a large markdown table in about 100ms on my laptop (which is many more emojis than will ever be in any normal issue). This also prevents any flickering and other weirdness from using javascript to render some things while using go for others.

Includes the optional download of a fallback emoji webfont for small number of users who don't already have one installed.

Fixes: https://github.com/go-gitea/gitea/issues/9182 Fixes: https://github.com/go-gitea/gitea/issues/8974 Fixes: https://github.com/go-gitea/gitea/issues/8953 Fixes: https://github.com/go-gitea/gitea/issues/6628 Fixes: https://github.com/go-gitea/gitea/issues/5130

I would like to integrate a proper process to create real system packages and distribute them via Bintray, than users can just add a deb/rpm repository and got a clean upgrade path.

Beside that we can also publish our releases to a static page or also to Bintray for download.

This adds the functionality to auto merge a pull request, once all status checks succeed.

To achieve this, it schedules a pr to merge when a user request a merge via API and set merge_when_checks_succeed to true. On every status check update, if there are scheduled merge requests for this pull and that pull pass all merge requirements, they get merged.

I created fake statuses for testing by running curl -X POST "http://localhost:3000/api/v1/repos/kolaente/testing/statuses/ccd425c09136a411236830785c41afdc172e8208" -H "accept: application/json" -H "authorization: Basic a29sYWVudGU6anVwMjAwMA==" -H "Content-Type: application/json" -d '{"context": "test/context", "description": "description", "state": "pending", "target_url": "http://localhost"}' | jq

TODO

• [x] Show on the pr page if a pr was scheduled for auto merge
  • [x] Add a comment {User} scheduled this pr to auto-merge
• [x] Provide an option to bypass auto merge entirely and merge directly without waiting for status checks
• [x] Provide an option to cancel auto merge once it's set
• [x] Add a check to see if all checks already succeeded in routers/repo/pull.go:676 to prevent scheduling a pr for merging after all checks already passed.
• [x] Only check if all required status checks succeeded or all if none are required in services/automerge/pull_auto_merge.go:89
• [x] Add an event comment to the pr timeline if it was set/unset to auto merge
• [x] Make sure to check all prs with the same head branch of a commit for merging PRs when a check succeeds
• [x] Fix dropdown button width of the merge button
• [x] Allow both directly merging and scheduling for merge
• [x] Add "merge now" button next to "merge when checks succeed"
• [x] Cleanup scheduled pr merge when it failed to get merged + log error
• [x] Move handling to [a queue](example: https://github.com/go-gitea/gitea/pull/19390)
• [x] Check permissions again right before merging
• [x] Automerge does not respect other branch protections yet
• [x] ~~pull_service.Merge() need a lock~~ -> move it into won pull (#19520)
• [ ] ~~Fix UI glitch to Create AutoMerge~~ -> new issue ... new pull #19621
• [x] API cancel auto-merge

Optional TODOs

• [ ] Show auto merge status on PR list

close #3905

Changes

• Refactored user creation (code deduplication, see individual commit messages: a3366c4 and 6e2ece4)
• Added auto-registration for OAuth2 users

Settings

A new settings section (oauth2_client) is added and documented in custom/conf/app.ini.sample and content/doc/advanced/config-cheat-sheet.en-us.md.

Breaking changes?

No. The default settings reflect the current behaviour. And OAuth2 auto-register needs to be manually enabled.

Referenced Issues

Implements #3520 und solves the secondary consideration in #1036.

Introduction

This PR implements dependencies for issues, as described in #2196.

It lets you define anonther issue as a dependency for an issue. You the cannot close the issue if it has any dependent issues which aren't closed. If you try to autoclose an issue via commit message which still has dependencies left, autoclose will simply not close the issue, but the commit will not fail.

You can disable dependencies in the repo settings.

Example: You set #2, #3 and #4 as a dependency of #1. Now you need to close all #2, #3 and #4, before you can close #1.

Screenshots

Overview of Issue Dependencies (sidebar):

Comments after adding a new dependency:

Questions

Currently, i would describe this as "working, but not finished", as there are some questions i have:

1. For now, you need the issue ID (not the index) to create a dependency. This is not very user-friendly, I'd like to have some kind of search bar where you search for the issue title/index select it, and it'll do the rest. Problem: There is no API-Endpoint to search for issues like that (Or just returns a list of all issues as JSON). I think this should be implemented first. If such thing already exists, please point me to it, I haven't found any.
2. It is currently possible to create dependencies with issues from other repositories. Is this okay? Or should one not be able to do this, as it could create a massive overhead with all permission-checking etc.
3. There is some work to be done with migrations etc, currently i simply put the xorm-call at the beginning of the function, which probably shouldn't be there. Where is the appropriate place to put this?

This is my first time I've done something like this in Go, before i've only played around with Go but never really did anything bigger. So, there are probably some things I didn't got right as a novice. Looking forward to hear your improvents to be made! Also thanks to @JonasFranzDEV who has helped me a lot.

Description

Since upgrading to 1.16.6, every push fails with the following error:

git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks push -v origin master:master
fatal: credential-cache unavailable; no unix socket support
POST git-receive-pack (2733 bytes)
remote: 
remote: Gitea: Internal Server Error        

In docker console this is logged:

Failed to open repository: Git/Data Error: exit status 128 - fatal: unsafe repository ('/data/git/repositories/git/data.git' is owned by someone else)

Downgrading to 1.16.5 makes it work again. UI works in 1.16.6 and also allows me to browse the files in this repository (or any other, all have this push error).

Gitea Version

1.16.6

Can you reproduce the bug on the Gitea demo site?

No

How are you running Gitea?

Windows Server 2022 + Docker. Windows 10 + Docker has the same problem.

• Gitea version (or commit ref): 1.8.1

• Git version: 2.21.0

• Operating system: windows10-1903

• Database (use [x]):

  • [ ] PostgreSQL
  • [x] MySQL
  • [ ] MSSQL
  • [x] SQLite

• Can you reproduce the bug at https://try.gitea.io:

  • [ ] Yes (provide example URL)
  • [ ] No
  • [x] Not relevant

• Log gist: not needed

Description

Gitea, as with gogs which it was forked from, has many accessibility issues with screen readers including:

1. The dropdown menus are clickables, so many screen readers do not know what to do with them as they do not use the mouse cursor.
2. The license selection/.gitignore selection (and most other menus of that type) are inaccessible, as they all use mouse oriented actions.
3. Possibly others I haven't seen yet.

Unfortunately, this is caused by the toolkit you use, which does not seem interested in making their toolkit accessible. It can be worked around with aria markup, or by changing toolkits (the first of which is easier to begin with but requires more maintenance over time, the second of which is of course much harder, but once you get it done it's done pretty much forever).

See the original issue on gogs for more info: gogs/gogs#3340

Looking forward to seeing if anything can be done about this. -dingpengyu. tests screen reader: NVDA thank

• Gitea version (or commit ref): 1.14.x
• Git version: 2.31.1
• Operating system: FreeBSD 13
• Gitea built using ports collection (www/gitea)
• Gitea started by startup script provided by www/gitea port
• Database (use [x]):
  • [x] PostgreSQL 12.6
  • [ ] MySQL
  • [ ] MSSQL
  • [ ] SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • [x] Yes (https://try.gitea.io/tsowa/FreeBSD_ports)
  • [ ] No
• Log gist: https://www.ttmath.org/gitea.log

Description

I saw a similar thread but there is "windows" in the title so I create a new issue. Gitea 1.14.x is much slower in repository browsing than Gitea 1.13.

Sample repo running with 1.14.1: https://gitea.ttmath.org/FreeBSD/ports Try to open any directory, for example: https://gitea.ttmath.org/FreeBSD/ports/src/branch/main/audio It takes between 50-150 seconds to open a page.

The same repo running with 1.13.7: https://giteaold.ttmath.org/FreeBSD/ports Try to open similar directory, for example: https://giteaold.ttmath.org/FreeBSD/ports/src/branch/main/audio I takes about 5 seconds.

You can see the same problem on try.gitea.io: https://try.gitea.io/tsowa/FreeBSD_ports But you have a cache so you have to find a directory which was not open before. Opening such a page takes 100-300 seconds.

Let me know if more info is needed.

• Gitea version (or commit ref): all
• Git version: all
• Operating system: all
• Database (use [x]):
  • [x] PostgreSQL
  • [x] MySQL
  • [x] SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • [x] Yes (provide example URL)
  • [ ] No
  • [x] Not relevant

Description

I am used to Gist, the pastebin service, since it offers me the option to collect all my pasted code in one central place and that in the same interface, text editor and so on, which i use on Github, so all is very consistent.

I suggest to implement such a service for Gitea too, as Gitlab does it with their snippets.

This is something we all use, it provides users and developers the very same look and feel as in Gitea, is easy to implement (so far i as a newbie can see) and offer us a history of all the already posted code.

• Gitea version (or commit ref): 1.10.2
• Git version: 2.25.0
• Operating system: ArchLinuxARM
• Database (use [x]):
  • [ ] PostgreSQL
  • [ ] MySQL
  • [ ] MSSQL
  • [x] SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • [ ] Yes (provide example URL)
  • [x] No: https://try.gitea.io/mxt92822/empty_test
  • [ ] Not relevant
• Log gist: https://gist.github.com/kauron/136587e6abf7611481d7461000eb8c4d

Description

Exactly the same as in #9365, but the filesystem is mounted with exec. I think the localhost API calls are the hooks, but I'm not sure. The hooks in the repo run properly when executed manually through the terminal.

(description copied from the previously mentioned issue)

I created a new repo and pushed a local repository. I tried it both with --all (it has two branches) and without (pushed only master). Either way the repository is not changed to non-empty. I did it manually in the DB to set the is_empty column to 0 which fixed the problem.

Description

Per gitea --help, the correct order of arguments is as follows:

gitea [global options] command [command options] [arguments...]

and the global options list includes

GLOBAL OPTIONS:
   ...
   --quiet, -q                    Only display Fatal logging errors until logging is set-up
   --verbose                      Set initial logging to TRACE level until logging is properly set-up

However, executing gitea -q web does not work (the initial logger level is still Info rather than Fatal) while gitea web -q does work.

It seems quiet is actually defined as a subcommand-specific cli boolean flag in web.go for the web subcommand associated with the runWeb action:

https://github.com/go-gitea/gitea/blob/d42b52fcfa4b175810e8da6bc1a8822838ff6456/cmd/web.go#L51-L53

I'd file a PR but I'm not clear on the intended behavior. It seems that the concept of global options might be altogether incorrect here since the switch is defined for a specific command and in runWeb the context associated with that particular command is queried for quiet, so it seems like you might prefer that the output/organization of gitea --help be patched rather than the actual querying behavior. I'm not sure if --quiet was previously a global option and now it's a command-specific one or if it's really only meant when running gitea -q rather than gitea -q web.

Gitea Version

1.19.0+dev-43-g57df0f116

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

N/A

Operating System

FreeBSD

How are you running Gitea?

Self-hosted, from the command-line.

Database

PostgreSQL

Description

Hello.

The changes in https://github.com/go-gitea/gitea/pull/21124, specifically here cause the repo file browser to overflow off the page when the most recent commit message has a long first line, which happens a lot when using the Gitea UI to merge two branches with median-length first lines, by default.

By having display: inline, the .commit-list .message-wrapper in the repository file browser doesn't respect the max-width to prevent overflow.

Changing display: inline to display: inline-block fixes the issue on the repository page, but breaks the changes in the above PR, otherwise I would have submitted a PR for it.

I cannot reproduce on the Gitea demo site because it won't allow me to create an account (500 error).

Screenshots

(Sorry for the obfuscation, I couldn't create an account on the demo site, otherwise I would have used that.)

Gitea Version

1.18.0

Can you reproduce the bug on the Gitea demo site?

No

Operating System

Linux

Browser Version

Firefox 108.0, Google Chrome 108.0.5359.124

Feature Description

Hello,I need to create a branch from tag through the API interface. I have searched the documentation and did not find this interface, so if you can support it, thank you very much.

Screenshots

No response

In some cases, the loading failure of index.js is not related to the ROOT_URL directly, ex: https://gitea.com/gitea/helm-chart/issues/392

If the user's reversed proxy is mis-configured: http://public-domain/gitea/xxx -> http://gitea:3000/gitea/xxx, it also causes the loading failure.

So this PR removes the ROOT_URL related tip from the error message.

Description

It is not possible to create issues or pull requests, trying to do so results in http status 500. Here is what I think is the relevant log:

2023/01/03 16:30:50 ...rs/web/repo/issue.go:1086:NewIssuePost() [I] [63b44a2a] [SQL] BEGIN TRANSACTION [] - 222.3µs
2023/01/03 16:30:50 ...vices/issue/issue.go:26:NewIssue() [I] [63b44a2a] [SQL] UPDATE issue_index SET max_index=max_index+1   WHERE group_id=? [1]
2023/01/03 16:30:50 ...vices/issue/issue.go:26:NewIssue() [I] [63b44a2a] [SQL] INSERT INTO issue_index (group_id, max_index) VALUES (?, 0) [1] - 509.6µs
2023/01/03 16:30:50 ...vices/issue/issue.go:26:NewIssue() [I] [63b44a2a] [SQL] UPDATE issue_index SET max_index=max_index+1 WHERE group_id=? [1] - 179.5µs
2023/01/03 16:30:50 ...rs/web/repo/issue.go:1086:NewIssuePost() [I] [63b44a2a] [SQL] ROLLBACK []
2023/01/03 16:05:37 ...rs/web/repo/issue.go:1091:NewIssuePost() [E] [63b44441] NewIssue: generate issue index failed: impossible error when GetNextResourceIndex, insert and update both succeeded but no record is updated

If I run these querys myself through the console, they work as expected and also return the right amount of rows affected (1) but when run by gitea it seems to always return 0. https://github.com/go-gitea/gitea/blob/f7ade6de7c1c4991c650d6b96e6407053e6bdae7/models/db/index.go#L98-L103

The MSSQL version is 15.0.2095.3

Gitea Version

1.18

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

Windows 10

How are you running Gitea?

I'm using this binary: https://dl.gitea.io/gitea/1.18.0/gitea-1.18.0-windows-4.0-amd64.exe

Database

MSSQL