Private Issues, Web UI: Investigate and implement the milestone changes on a private issue #518
Labels
No labels
ai-review-please
Org/Team Modification
Private Issues
Runner Request
Backlog Status
Needs Review
Backlog Status
Ready
chore
documentation
points
01
points
02
points
03
points
05
points
08
points
13
Priority
High
Priority
Low
Priority
Medium
Sprint Status
Blocked
Sprint Status
Done
Sprint Status
In Progress
Sprint Status
Review
Sprint Status
To Do
Technical Debt
Work Item
Bug
Work Item
Epic
Work Item
Spike
Work Item
Task
Work Item
User Story
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Blocks
Depends on
Reference
forge/forge#518
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Private Issues, Web UI: Investigate and implement the milestone changes on a private issue
Details
Private Issues, Web UI: Investigate and implement the milestone changes on a private issue
Whenever the milestone associated to a private issue is changed, we need to see how it gets reflected on the history timeline, how it shows up under the milestone listing, who can access it from under the milestone listing and whether we inadvertently expose the private issue.
I am blocked now. Yet again.
What's new in that?Here's why.I was implementing the sidebar support for milestone changes. I found that the frontend template and router fixes (i.e. passing
is_privatein HTMX URLs, queryingprivate_commentin HTMX response), made the sidebar interaction work correctly.But the said change does not persist on refreshing frontend. It simply goes away. Now, this stupid problem is not specific to milestone changes, it seems to affect all comment types on private issues - and hence, needs to be fixed first.
FindCommentsalways queries thecommenttable. It should query theprivate_commenttable, no? I mean,CreateCommentdoes correctly create it at the intended location so this needs to be fixed on the database backend before views.I have a fix. I think it works. I will open up a new issue ticket for that. Once, this foundational change is introduced to the database backend, I can finally go back to fixing things on the frontend templates. Then we would have new problems.
See https://codeberg.org/fedora/forgejo/pulls/105.
Draft state. Until https://codeberg.org/fedora/forgejo/pulls/104 gets merged.
https://codeberg.org/fedora/forgejo/pulls/105 was finally merged.
Closing this!
data-is-privatedata-is-private