#6261 closed bug (fixed)
Bug in adding attachments with patch flag set
| Reported by: | andreasf | Owned by: | nielx |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Website/Trac | Version: | |
| Keywords: | attachmentflags | Cc: | |
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
For me a common Trac use case is that I file a ticket and immediately attach a patch ("I have files to upload"). Since the new attachment flags feature, adding the initial attachment as a patch leads to the attachment being added without description, then an empty numbered comment 1 ("Reply" overlaps following one!), followed by a non-numbered comment with the patch description and finally a numbered comment with the "patch set" change. See #6061. In the Attachments list the description is shown correctly though.
It would be really nice to have the description accompany the patch again and even better to have any automatic history items not as numbered reply'able comments.
(from email)
Change History (5)
follow-up: 2 comment:1 by , 14 years ago
comment:2 by , 14 years ago
Replying to andreasf:
For #6260 this worked just fine - could be related to the Trac upgrade or the elevated priviledges?
Definitely not the upgrade, since I did not modify the attachmentflags module. The elevated privileges ... I don't think so either, but I should check. Maybe in some of the trac functions I call the privileges are checked.
follow-up: 4 comment:3 by , 14 years ago
Actually, looking back at #6061, I don't think it is a bug, but intended behavior. You should imagine that the attachmentflags module overrides two systems, the attachment system and the ticket system. In Trac these two are separate so that the same attachment subsystem can be used for the wiki pages.
The plugin overrides the attachment listing/viewing/adding functionality of the attachment subsystem, and the custom fields of the ticket subsystem.
If you add an attachment to a ticket (wiki/other attachments are ignored) then the flags field are shown. If any field is checked, the system will determine whether it is a patch or not (obsolete flag overrides the patch flag). It also looks at other attachments for the ticket, so if you have two attachments with a patch flag set, and you obsolete one, then the ticket still has a patch. Then it determines whether it should set/unset the patch field in the ticket system.
What happened in ticket #6061 is that you added an attachment with the patch flag set. The attachmentflags module then decides to tell the ticket module to set the patch flag (which is the numbered comment). The other attachments do not change the patch flag, so no numbered comments for those.
Web apps are by nature not state aware, so adding the attachments in a row and then adding the 'Has a patch' comment afterwards needs some unclean hacking in the code.
comment:4 by , 14 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
You're judging an old bug report based on the new Trac version. The comment display has apparently changed and is to my satisfaction now.
It wasn't about attachments in a row, it's about having the initial one attachment addition as one atomic history item along with its description. Before, it was three items as described above, one for the attachment, one for the property and one (late) for the patch description. Now adding a new patch is shown as two history items, one for the added attachment and one for the 'Has a patch' property change.
Thanks, closing this as fixed.
For #6260 this worked just fine - could be related to the Trac upgrade or the elevated priviledges?