Opened 15 years ago
Closed 14 years ago
#5599 closed defect (invalid)
Deleting a blocking/blocked by ticket does not fully destroy the relationship
Reported by: | Owned by: | Noah Kantrowitz | |
---|---|---|---|
Priority: | highest | Component: | MasterTicketsPlugin |
Severity: | blocker | Keywords: | |
Cc: | Trac Release: | 0.11 |
Description
When deleting a relationship in a blocking/blocked by field, the following things should happen:
- The blocking/blocked by field of the current ticket should be removed (and change history updated)
- The blocked by/blocking field for the referenced ticket should be removed (and change history updated)
- The relationship in the mastertickets table should be removed.
Currently, only #1 is happening. The code for this scenario in model.py appears to work fine, the problem is that the ticket_changed function in api.py only adds to the blocking/blocked_by attributes of the link, apparently expecting these sets to be empty. TicketLinks init function, however, populates these attributes with the existing relationships and makes a copy so it can determine the delta on an update. The net effect is that you can never really delete a relationship. To make matter worse, post_process_request is reporting changes based on the text fields, so the user sees relationships "added" and "removed" when in fact only the ticket property changed.
In our local environment, I added the following two lines before the for loops in the ticket_changed function:
links.blocking.clear() links.blocked_by.clear()
The full function now looks like this:
def ticket_changed(self, tkt, comment, author, old_values):
db = self.env.get_db_cnx()
links = TicketLinks(self.env, tkt, db)
links.blocking.clear() links.blocked_by.clear() for s in set(self.NUMBERS_RE.findall(tktblocking? or )):
links.blocking.add(int(s))
for s in set(self.NUMBERS_RE.findall(tktblockedby? or )):
links.blocked_by.add(int(s))
links.save(author, comment, tkt.time_changed, db)
db.commit()
Attachments (1)
Change History (2)
Changed 15 years ago by
Attachment: | 5599.patch added |
---|
comment:1 Changed 14 years ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
This bug is only due to incorrect code in another patch you applied. As written in trunk this works fine.
patch that solves this bug