Activity log

Hi, everyone,

my employer wants me to enter my activities into a (rather
rotten) database. Most of these leave some traces in the
bugtracker, so I wonder if it would be possible to have
Roundup generate a useful overview. It could come from a
table, initialized via a script and maintained using
detectors (and most likely should be available to the owner
of the activities).

Of course it should be possible to use the journal; but this
is difficult anyway, and often I view an issue and start
working on it without applying any change immediately (would
it be possible to log read accesses there?)

Thus, it came to my mind to create an "activity"
table which would contain

- the owner of the activity (link)
- the issue (link)
- the timestamp
- the type[s] of activity (e.g. create, change, comment,
read,
  merge/retire, restore)

This would allow me to write an extension which would yield
a nice activity summary for a particular day, ordered by
time, and with adjacent entries refering to the same issue
grouped together.

Any thoughts?
-- 
TIA,

Tobias


------------------------------------------------------------
-------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the
chance to share your
opinions on IT & business topics through brief
surveys-and earn cash
http://www.techsay.com/default.
php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Roundup-users mailing list
Roundup-userslists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/roundup-u
sers

On Fri, 23 Mar 2007, Tobias Herp wrote:
> Of course it should be possible to use the journal; but
this is difficult
> anyway, and often I view an issue and start working on
it without applying
> any change immediately (would it be possible to log
read accesses there?)

Ouch. I guess so, if you had a javascript call from the item
page which 
invoked a simple edit operation to add a new entry to your
"activity" table.


> Thus, it came to my mind to create an
"activity" table which would contain
>
> - the owner of the activity (link)
> - the issue (link)
> - the timestamp
> - the type[s] of activity (e.g. create, change,
comment, read,
>   merge/retire, restore)
>
> This would allow me to write an extension which would
yield a nice activity
> summary for a particular day, ordered by time, and with
adjacent entries
> refering to the same issue grouped together.

Having the actvity table duplicate the journal for the
non-read operations 
seems unfortunate.


     Richard

------------------------------------------------------------
-------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the
chance to share your
opinions on IT & business topics through brief
surveys-and earn cash
http://www.techsay.com/default.
php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Roundup-users mailing list
Roundup-userslists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/roundup-u
sers

Richard Jones wrote:
> On Fri, 23 Mar 2007, Tobias Herp wrote:
>   
>> Of course it should be possible to use the journal;
but this is difficult
>> anyway, and often I view an issue and start working
on it without applying
>> any change immediately (would it be possible to log
read accesses there?)
>>     
>
> Ouch. I guess so, if you had a javascript call from the
item page which 
> invoked a simple edit operation to add a new entry to
your "activity" table.
>   
I thought of a detector, triggering the "view"
action. Would this be 
possible?

>> Thus, it came to my mind to create an
"activity" table which would contain
>>
>> - the owner of the activity (link)
>> - the issue (link)
>> - the timestamp
>> - the type[s] of activity (e.g. create, change,
comment, read,
>>   merge/retire, restore)
>>
>> This would allow me to write an extension which
would yield a nice activity
>> summary for a particular day, ordered by time, and
with adjacent entries
>> refering to the same issue grouped together.
>>     
>
> Having the actvity table duplicate the journal for the
non-read operations 
> seems unfortunate.
>   

Yes; but it could ease the pain to allow users to cleanup
their activity 
log (up to a given date), and to log activities only for
users with a 
certain role. The activity table would IMO need to contain
*all* 
operations, including those contained in the journal.

Having a "read" or "view" entry in the
journal for every read access 
would, of course, blow up the issue history.

However, it might be worth a try to implement the activity
overview 
without a new table first. Can you give me a pointer how to
accomplish 
this? The db.getjournal method looks at a given issue,
rather than at 
all issue operations of a given user; thus I would need to
read all 
journals of all issues just to get the activity info. This
sounds not 
very efficient to me.

The activity table would need an index on owner and one on
the 
timestamp; should be possible using schema.py, right?

Cheers,

'Tobias



------------------------------------------------------------
-------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the
chance to share your
opinions on IT & business topics through brief
surveys-and earn cash
http://www.techsay.com/default.
php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Roundup-users mailing list
Roundup-userslists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/roundup-u
sers

On Fri, 23 Mar 2007, Tobias Herp wrote:
> Richard Jones wrote:
> > On Fri, 23 Mar 2007, Tobias Herp wrote:
> >> Of course it should be possible to use the
journal; but this is
> >> difficult anyway, and often I view an issue
and start working on it
> >> without applying any change immediately (would
it be possible to log
> >> read accesses there?)
> >
> > Ouch. I guess so, if you had a javascript call
from the item page which
> > invoked a simple edit operation to add a new entry
to your "activity"
> > table.
>
> I thought of a detector, triggering the
"view" action. Would this be
> possible?

No. If you want to trigger off viewing the web page you need
to have something 
in the web page that does the work.


> However, it might be worth a try to implement the
activity overview
> without a new table first. Can you give me a pointer
how to accomplish
> this? The db.getjournal method looks at a given issue,
rather than at
> all issue operations of a given user; thus I would need
to read all
> journals of all issues just to get the activity info.
This sounds not
> very efficient to me.

Ah, yes.


> The activity table would need an index on owner and one
on the
> timestamp; should be possible using schema.py, right?

The Roundup hyperdb knows nothing about indexes. It
automatically implements 
some at a lower level for relational databases. If you were
to add indexes 
for additional columns it wouldn't affect Roundup.

If you're using a relational db backend you could also poke
directly at the 
journal table to perform the queries you're interested in.


     Richard

------------------------------------------------------------
-------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the
chance to share your
opinions on IT & business topics through brief
surveys-and earn cash
http://www.techsay.com/default.
php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Roundup-users mailing list
Roundup-userslists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/roundup-u
sers

On Fri, 23 Mar 2007 18:06:43 +1100, Richard Jones wrote:
> On Fri, 23 Mar 2007, Tobias Herp wrote:
> > I thought of a detector, triggering the
"view" action. Would this be
> > possible?
> 
> No. If you want to trigger off viewing the web page you
need to have
> something in the web page that does the work.

Let's see. I would need to open a minimized background
window which contains a form which is submitted
automatically and creates the activity log entry. Using an
additional issue field would blow up the history (for every
page refresh), and using an existing field could cause
conflicts when submitting changes, right?

> > The activity table would need an index on owner
and one on the
> > timestamp; should be possible using schema.py,
right?
> 
> The Roundup hyperdb knows nothing about indexes. It
automatically
> implements some at a lower level for relational
databases.

Let me guess: for "id" and "order"
fields and those given in (Class).setkey and
(Class).setorderprop calls?

> If you were to add indexes
> for additional columns it wouldn't affect Roundup.

You mean, it wouldn't care; but the database system would
use them automagically (well, it should).

> If you're using a relational db backend you could also
poke directly
> at the journal table to perform the queries you're
interested in.

Yes, I do (currently sqlite). In this case, and additionally
using the journal for the operations it covers, this would
imply a UNION with an ORDER BY clause (http://www.sql
ite.org/lang_select.html).

-- 
Cheers,

Tobias


------------------------------------------------------------
-------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the
chance to share your
opinions on IT & business topics through brief
surveys-and earn cash
http://www.techsay.com/default.
php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Roundup-users mailing list
Roundup-userslists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/roundup-u
sers