Description of problem:
1. Opened Overview
2. Selected last entry
3. Right click on the entry
4. Select "Add new"
Version-Release number of selected component:
cmdline: /usr/bin/python /usr/bin/hamster-windows-service
runlevel: N 5
overview.py:385:on_add_activate:TypeError: 'Fact' object has no attribute '__getitem__'
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/hamster/overview.py", line 385, in on_add_activate
selected_date = fact["date"]
TypeError: 'Fact' object has no attribute '__getitem__'
Local variables in innermost frame:
action: <gtk.Action object at 0x2278fa0 (GtkAction at 0x239cd80)>
self: <Overview object at 0x221feb0 (hamster+overview+Overview at 0x21b9e80)>
fact: <hamster.lib.Fact object at 0x2642f90>
Potential duplicate: bug 1044531
Created attachment 873033 [details]
Created attachment 873034 [details]
Thank you for your bug report.
On my system here, right clicking and using "add new" does nothing at all (which is a separate bug really). Can you reproduce your bug consistently?
(Even Activity -> add new does nothing here)
yes it is reproducible, when tracking is running.
1. select the running activity
2. right-click on the running activity
3. select "add new"
Abrt will show up...
(In reply to Soeren Grunewald from comment #5)
> Hi Ankur,
> yes it is reproducible, when tracking is running.
> 1. select the running activity
> 2. right-click on the running activity
> 3. select "add new"
> Abrt will show up...
Interesting. It isn't crashing for me here. Can you please check the screencast to see if I'm doing the correct steps:
It just doesn't do anything, but abrt isn't coming up yet.
Created attachment 875922 [details]
Hi, It looks a bit different, i will try to reproduce it. For now, see attached screen-cast how i use it.
Created attachment 881660 [details]
Using hamster the same way
Finally I found the time to do it the same way as shown in your sample. The issue does also appear.
Not sure what's going on in that code. Sometimes "facts" are dictionaries, and sometimes they are "Fact" objects. Some refactoring in progress I guess...
Anyway, to fix this particular bug you should replace fact["date"] with fact.date.
Can we get a fix for this anytime soon?
I missed your earlier comment somehow. I'll look at it this week.
*** Bug 1044531 has been marked as a duplicate of this bug. ***
Building an update. Also reported upstream: https://github.com/projecthamster/hamster/issues/201
hamster-time-tracker-1.04-4.fc20 has been submitted as an update for Fedora 20.
hamster-time-tracker-1.04-4.fc21 has been submitted as an update for Fedora 21.
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing hamster-time-tracker-1.04-4.fc21'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
hamster-time-tracker-1.04-4.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
hamster-time-tracker-1.04-4.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.