Pre-fill new issue Labels from URL parameter #11745

New Issue

GiteaMirror · 2025-11-02T09:46:30-06:00

GiteaMirror commented

2025-11-02 09:46:30 -06:00

Originally created by @h0lg on GitHub (Sep 28, 2023).

Feature Description

If it was possible to pre-fill the Labels of a new issue from a URL parameter, I could link users from different components of a host app to the new issue form and help everyone involved to categorize the new issue correctly.

Correct categorization would allow further integration of issue tracking into a host app, like listing all open issues or FAQ for a component.

Imagine /issues/new?labels=kind/bug,area/dashboard which would pre-fill the Labels with kind/bug and area/dashboard.

Or /issues/new/choose?labels=area/dashboard which could patch the area/dashboard through and apply it on top of whatever labels are configured in the issue template the user chooses.

This would be an enhancement of the current behaviour which pre-fills the new issue form's title, body, milestone and project from URL parameters:

3fcad582c9/routers/web/repo/issue.go (L914-L950)

I didn't find this behaviour described in the API docs, but something similar for creating new files.

Originally created by @h0lg on GitHub (Sep 28, 2023). ### Feature Description If it was possible to pre-fill the _Labels_ of a new issue from a URL parameter, I could link users from different components of a host app to the new issue form and help everyone involved to categorize the new issue correctly. > Correct categorization would allow further integration of issue tracking into a host app, like listing all open issues or FAQ for a component. Imagine `/issues/new?labels=kind/bug,area/dashboard` which would pre-fill the _Labels_ with `kind/bug` and `area/dashboard`. Or `/issues/new/choose?labels=area/dashboard` which could patch the `area/dashboard` through and apply it on top of whatever labels are configured in the issue template the user chooses. This would be an enhancement of the current behaviour which pre-fills the new issue form's `title`, `body`, `milestone` and `project` from URL parameters: https://github.com/go-gitea/gitea/blob/3fcad582c9b9bfe66f4a346652f82b1aaf18430d/routers/web/repo/issue.go#L914-L950 I didn't find this behaviour described in the API docs, but [something similar for creating new files](docs.gitea.com/development/integrations?_highlight=pre&_highlight=fill#pre-fill-new-file-name-and-contents).

GiteaMirror added the type/proposal label 2025-11-02 09:46:30 -06:00

GiteaMirror commented

2025-11-02 09:46:31 -06:00

@eeyrjmr commented on GitHub (Sep 28, 2023):

Would issue templates be better instead as you can preset desired labels for different templates on a per-repo basis

@eeyrjmr commented on GitHub (Sep 28, 2023): Would issue templates be better instead as you can preset desired labels for different templates on a per-repo basis

GiteaMirror commented

2025-11-02 09:46:31 -06:00

@h0lg commented on GitHub (Sep 28, 2023):

Would issue templates be better instead as you can preset desired labels for different templates on a per-repo basis

I don't thinks so. Let's say I have 50 distinct components or pages in my app. I'd rather create 50 labels to "map" them to my gitea repo than maintain 50 issue templates.

@h0lg commented on GitHub (Sep 28, 2023): > Would issue templates be better instead as you can preset desired labels for different templates on a per-repo basis I don't thinks so. Let's say I have 50 distinct components or pages in my app. I'd rather create 50 labels to "map" them to my gitea repo than maintain 50 issue templates.

GiteaMirror commented

2025-11-02 09:46:31 -06:00

@JakobDev commented on GitHub (Sep 29, 2023):

There are also repo owner who don't want that users can set labels themself. Your use case sounds very specific.

@JakobDev commented on GitHub (Sep 29, 2023): There are also repo owner who don't want that users can set labels themself. Your use case sounds very specific.

GiteaMirror commented

2025-11-02 09:46:31 -06:00

@h0lg commented on GitHub (Oct 3, 2023):

There are also repo owner who don't want that users can set labels themself.

Good point - I can understand that setting them from the URL only works if you allow setting them at all. That's a different question though and can be answered on a per-repo or per-issue-type basis. Do you trust your users to be competent enough collaborators? The way I use gitea, I'd love their support in categorizing an issue properly by labelling/tagging.
But note that pre-setting the labels from the URL would actually take that work off their hands most of the time. For sure, you may have to fix the labels sometimes when users apply the wrong ones. But you already have to do that if you do it manually.

Also note that the same argument could be applied to milestone and project - I imagine some repo owners don't want their users to set those, yet the API to do so from the URL exists.

Your use case sounds very specific.

Does it? Too specific for gitea? I feel this is not a far-fetched request considering the existence of similar APIs for similar process-related issue properties.

Also, the potential benefits of automating the labelling of issues to are huge:

You can filter issues for any label easily without wasting time on manual categorization.
Ever encountered a poorly written bug report that misses basic info, like where in your app it occurred? Automatic labelling may fill in that missing context, eliminating an additional feedback loop.

@h0lg commented on GitHub (Oct 3, 2023): > There are also repo owner who don't want that users can set labels themself. Good point - I can understand that setting them from the URL only works if you allow setting them at all. That's a different question though and can be answered on a per-repo or per-issue-type basis. Do you trust your users to be competent enough collaborators? The way I use gitea, I'd love their support in categorizing an issue properly by labelling/tagging. But note that pre-setting the labels from the URL would actually take that work off their hands most of the time. For sure, you may have to fix the labels sometimes when users apply the wrong ones. But you _already_ have to do that if you do it manually. Also note that the same argument could be applied to `milestone` and `project` - I imagine some repo owners don't want their users to set those, yet the API to do so from the URL exists. > Your use case sounds very specific. Does it? Too specific for gitea? I feel this is not a far-fetched request considering the existence of similar APIs for similar process-related issue properties. Also, the potential **benefits of automating the labelling of issues** to are huge: - You can **filter issues for any label easily without wasting time on manual categorization**. - Ever encountered a poorly written bug report that misses basic info, like _where_ in your app it occurred? Automatic labelling may **fill in that missing context**, eliminating an additional feedback loop.

GiteaMirror commented

2025-11-02 09:46:32 -06:00

@h0lg commented on GitHub (Jan 9, 2024):

I successfully implemented this by adding a custom footer.tmpl with the following contents to my $GITEA_CUSTOM/templates/custom folder:

<script>
$(() => {
    // pre-selects new issue labels from query string parameter in the form of labels=kind/bug,area/dashboard
    if (location.pathname.endsWith('/issues/new')) { // only run on new issue page
        const urlParams = new URLSearchParams(location.search),
            joinedLabels = urlParams.get('labels');

        if (joinedLabels !== null) {
            const addedLabels = joinedLabels.split(','),

                // case-insensitive string comparison; see https://stackoverflow.com/a/2140723
                labelEquals = (a, b) => a.localeCompare(b, undefined, { sensitivity: 'accent' }) === 0,

                // find matching labels in dropdown menu by text
                $items = $('.menu .item .ui.label', '.select-label.dropdown')
                    .filter((_i, label) => addedLabels.some(added => labelEquals(added, label.innerText)))
                    .map((_i, label) => label.closest('.item')); // and select their closest items

            $items.trigger('click'); // selects matching items
        }
    }
});
</script>

@h0lg commented on GitHub (Jan 9, 2024): I successfully implemented this by [adding a custom](https://docs.gitea.com/advanced/customizing-gitea) `footer.tmpl` with the following contents to my `$GITEA_CUSTOM/templates/custom` folder: ```HTML <script> $(() => { // pre-selects new issue labels from query string parameter in the form of labels=kind/bug,area/dashboard if (location.pathname.endsWith('/issues/new')) { // only run on new issue page const urlParams = new URLSearchParams(location.search), joinedLabels = urlParams.get('labels'); if (joinedLabels !== null) { const addedLabels = joinedLabels.split(','), // case-insensitive string comparison; see https://stackoverflow.com/a/2140723 labelEquals = (a, b) => a.localeCompare(b, undefined, { sensitivity: 'accent' }) === 0, // find matching labels in dropdown menu by text $items = $('.menu .item .ui.label', '.select-label.dropdown') .filter((_i, label) => addedLabels.some(added => labelEquals(added, label.innerText))) .map((_i, label) => label.closest('.item')); // and select their closest items $items.trigger('click'); // selects matching items } } }); </script> ```

GiteaMirror commented

2025-11-02 09:46:32 -06:00

@h0lg commented on GitHub (May 27, 2024):

This updated script works for v1.22:

<script>
$(() => {
    // pre-selects new issue labels from query string parameter in the form of labels=kind/bug,area/dashboard
    if (location.pathname.endsWith('/issues/new')) { // only run on new issue page
        const urlParams = new URLSearchParams(location.search),
            joinedLabels = urlParams.get('labels');

        if (joinedLabels !== null) {
            const addedLabels = joinedLabels.split(','),

                // gets the innerText of the first descandant with class descendantClass
                getFirstText = (element, descendantClass) => element.getElementsByClassName(descendantClass)[0].innerText,

                // case-insensitive string comparison; see https://stackoverflow.com/a/2140723
                labelEquals = (a, b) => a.localeCompare(b, undefined, { sensitivity: 'accent' }) === 0,

                // find matching labels in dropdown menu by text
                $items = $('.menu .item .scope-parent', '.select-label.dropdown')
                    .filter((_i, label) => {
                        const synthdText = getFirstText(label, 'scope-left') + '/' + getFirstText(label, 'scope-right');
                        return addedLabels.some(added => labelEquals(added, synthdText));
                    })
                    .map((_i, label) => label.closest('.item')); // and select their closest items

            $items.trigger('click'); // selects matching items
        }
    }
});
</script>

@h0lg commented on GitHub (May 27, 2024): This updated script works for **v1.22**: ```js <script> $(() => { // pre-selects new issue labels from query string parameter in the form of labels=kind/bug,area/dashboard if (location.pathname.endsWith('/issues/new')) { // only run on new issue page const urlParams = new URLSearchParams(location.search), joinedLabels = urlParams.get('labels'); if (joinedLabels !== null) { const addedLabels = joinedLabels.split(','), // gets the innerText of the first descandant with class descendantClass getFirstText = (element, descendantClass) => element.getElementsByClassName(descendantClass)[0].innerText, // case-insensitive string comparison; see https://stackoverflow.com/a/2140723 labelEquals = (a, b) => a.localeCompare(b, undefined, { sensitivity: 'accent' }) === 0, // find matching labels in dropdown menu by text $items = $('.menu .item .scope-parent', '.select-label.dropdown') .filter((_i, label) => { const synthdText = getFirstText(label, 'scope-left') + '/' + getFirstText(label, 'scope-right'); return addedLabels.some(added => labelEquals(added, synthdText)); }) .map((_i, label) => label.closest('.item')); // and select their closest items $items.trigger('click'); // selects matching items } } }); </script> ```

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#11745