#27 labels can not be edited after issue creation

Closed
opened 7 months ago by chrisrandom · 15 comments

labels are not stored, if you want to add a label to an already existing issue. page gets reloaded, but label was not set.

labels are not stored, if you want to add a label to an already existing issue. page gets reloaded, but label was not set.
ashimokawa commented 7 months ago
Owner

Confirmed, also on other instances

Confirmed, also on other instances
chrisrandom commented 7 months ago
Poster

the problem seems to be a POST request which is triggered on selecting the label. since the page gets reloaded, it seems that the request gets interrupted. If you wait for some seconds to get the POST request to be finished, before clicking somewhere (which triggers the page reload), the problem is gone. at least for me

the problem seems to be a POST request which is triggered on selecting the label. since the page gets reloaded, it seems that the request gets interrupted. If you wait for some seconds to get the POST request to be finished, before clicking somewhere (which triggers the page reload), the problem is gone. at least for me
ashimokawa commented 6 months ago
Owner

For me this issue was a misunderstanding, I could not add labels because I did not set up labels for this repo. Very confusing, and yes, page reloads

For me this issue was a misunderstanding, I could not add labels because I did not set up labels for this repo. Very confusing, and yes, page reloads

Is the slow REST response a byproduct of running on a skeleton infrastructure? Or is there an issue in the request? The UI in the case of adding tags doesn’t have much in the way of request confirmation (there’s no green checkmark that shows up when the response comes back), so the route should be one directional. Update the database on click and that’s that.

Is the slow REST response a byproduct of running on a skeleton infrastructure? Or is there an issue in the request? The UI in the case of adding tags doesn't have much in the way of request confirmation (there's no green checkmark that shows up when the response comes back), so the route should be one directional. Update the database on click and that's that.
hw commented 6 months ago
Owner

It’s not a technical issue, but a bit unintuitive UI: you can enable a labelset and create new labels using the labels/milestones button at the top of the page.

Then you can add them

It’s not a technical issue, but a bit unintuitive UI: you can enable a labelset and create new labels using the labels/milestones button at the top of the page. Then you can add them

ahh

ahh
chrisrandom commented 6 months ago
Poster

in my case, i already had labels created and some tagged to the issue, but i wanted to edit them (adding or removing one). i thought that this request does not need confirmation, like scott-joe mentioned above, but for some reasons, the update of the labels only succeeded if i wait for the response of the request

in my case, i already had labels created and some tagged to the issue, but i wanted to edit them (adding or removing one). i thought that this request does not need confirmation, like scott-joe mentioned above, but for some reasons, the update of the labels only succeeded if i wait for the response of the request
hw added the
New Label
label 6 months ago
hw commented 6 months ago
Owner

Hm, the user interface definitely has room for improvement, but functionality works. (Add label+edit tested via labels/milestones button at top of page).

What browser are you using?

Hm, the user interface definitely has room for improvement, but functionality works. (Add label+edit tested via labels/milestones button at top of page). What browser are you using?
chrisrandom commented 6 months ago
Poster

Firefox (Fedora 29 repo version)

Firefox (Fedora 29 repo version)
ashimokawa added the
invalid
label 6 months ago
ashimokawa commented 6 months ago
Owner

Actually it works here in Firefox

Actually it works here in Firefox
ashimokawa removed the
invalid
label 6 months ago
ashimokawa commented 5 months ago
Owner
Related to https://github.com/go-gitea/gitea/issues/6191 ?
chrisrandom commented 5 months ago
Poster

i think so.

i think so.
ashimokawa commented 5 months ago
Owner

This bug has been fixed upstream in master (not 1.7 branch), I plan to backport and deploy it on codeberg if it has not been backported by upstream by then.

This bug has been fixed upstream in master (not 1.7 branch), I plan to backport and deploy it on codeberg if it has not been backported by upstream by then.
ashimokawa added the
bug
label 5 months ago
ashimokawa removed the
bug
label 5 months ago
ashimokawa added the
bug
label 5 months ago
ashimokawa self-assigned this 5 months ago
ashimokawa commented 5 months ago
Owner

Ok I backported this fix to our codeberg branch, so it should work now!

@cysec Please test and close if fixed (unfortunately this race condition did not occur on my (too slow?) machines.

Ok I backported this fix to our codeberg branch, so it should work now! @cysec Please test and close if fixed (unfortunately this race condition did not occur on my (too slow?) machines.
chrisrandom commented 5 months ago
Poster

seems to work. thanks

seems to work. thanks
Sign in to join this conversation.
No Milestone
No Assignees
4 Participants
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
Cancel
Save
There is no content yet.