Comment 2 for bug 246636

I thought about a kind of fall back mechanism some time ago and unfortunately I did not find a good idea how this could fit into the current design of py-lp-bugs. I came to the conclusion that the best way to achieve such a fall back would be in the end user script, something like:

     =====
In [32]: from launchpadbugs.connector import ConnectBug

In [33]: TBug = ConnectBug("text")

In [34]: HBug = ConnectBug()

In [35]: tbug = TBug(20767)

In [36]: ttask = tbug.infotable[1]

In [37]: date_confirmed = ttask.date_confirmed

In [38]: if date_confirmed is None:
   ....: try:
   ....: hbug = HBug(20767)
   ....: date_confirmed = [i.date for i in hbug.activity if "openoffice.org" in i.what and i.new_value == "Confirmed"][-1]
   ....: except:
   ....: pass
   ....:
   ....:

In [39]: date_confirmed
Out[39]: LPTime(2008, 2, 10, 19, 26)
     =====

Bug getting good information out of activity logs is sometimes (especially for older bugreports) a pain, because there are sometimes some bugzilla values in activity logs, sometimes the names of the packages are different and they are also sometimes missing some information.

If you agree I would like to change the scope of this bugreport a little bit and add helper methods to the ActivityLog-class which works like
>>> bug.activity.get_date("confirmed", "openoffice.org")

Markus