action #58304

A personal activity view for developers

Added by coolo about 1 month ago. Updated 23 days ago.

Status:NewStart date:17/10/2019
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Feature requests
Target version:-
Difficulty:
Duration:

Description

I find it very easy to get lost when doing 2 things. I.e. having tests in developer mode or scheduling jobs from git repo - or commenting on issues.

As such I would like to filter for the things I did last to pick them up again

or, from #60053 :

I would like to have a link that lists all the tests that were started by me (or a specific user).
Related: It would be nice to see the user who has started in the overview page.


Related issues

Related to openQA Project - action #58184: [epic][use case] full version control awareness within op... Workable 23/03/2018
Related to openQA Project - action #12042: implement favorite job groups New 18/05/2016
Duplicated by openQA Project - action #60053: List all the tests I have started Rejected 19/11/2019

History

#1 Updated by okurz 25 days ago

  • Description updated (diff)

#2 Updated by okurz 25 days ago

  • Duplicated by action #60053: List all the tests I have started added

#3 Updated by mkittler 24 days ago

We already track job_create, job_restart and similar events by the user. So the audit log filtered by e.g. user:coolo would already show some activity but e.g. starting a developer mode session is missing. It wouldn't be hard to add missing audit events and to add a "My activity" button somewhere which would then display the filtered audit log. Of course this leaves the question which interesting audit events are missing.

It wouldn't be hurt to improve the usability of the audit log a little bit. E.g. instead of displaying { "id": "3595900", "result": { "3595900": 3597492 } } for a job_restart event we could show links to that jobs. (That could easily be done on the client-side via the DataTables API.)


That would be sufficient, right? I mean we don't want to duplicate the browser history.

#4 Updated by tinita 24 days ago

@mkittler So I guess once a job is created there is no connection to the user anymore?

#5 Updated by mkittler 24 days ago

@tinita As I said, the job_create audit event is created and that contains a reference to the user. That's why I proposed to implement this via the audit log. Otherwise we indeed needed to add a reference from the job to the user who created it.

#6 Updated by cdywan 23 days ago

mkittler wrote:

We already track job_create, job_restart and similar events by the user. So the audit log filtered by e.g. user:coolo would already show some activity but e.g. starting a developer mode session is missing. It wouldn't be hard to add missing audit events and to add a "My activity" button somewhere which would then display the filtered audit log. Of course this leaves the question which interesting audit events are missing.


It wouldn't be hurt to improve the usability of the audit log a little bit. E.g. instead of displaying { "id": "3595900", "result": { "3595900": 3597492 } } for a job_restart event we could show links to that jobs. (That could easily be done on the client-side via the DataTables API.)

That. I brought it up before but I guess I never ended up filing the ticket for it.

I'd suggest we

  1. Collect use cases
  2. Have a renderer for each event that renders it in a user-friendly way, my first thought would be to have controllers register "event renderers" - not sure if there's an obvious mojo-esque way of doing it (helpers?)
  3. Implement that in the audit log, which is arguably barely usable as-is
  4. Consider a separate view based on the implementation

#7 Updated by mkittler 23 days ago

@cdywan

to 2.: I would do the rendering only on the client with JavaScript/DataTables. So Mojo wouldn't be involved at all.

to 4.: That would be the last point, indeed. If we decide to go that far I think this view could still share most of the code with the audit log. The controller would only filter results for the current user by default and we obviously don't want the "User" column in that view.

#8 Updated by cdywan 23 days ago

mkittler wrote:

@cdywan


to 2.: I would do the rendering only on the client with JavaScript/DataTables. So Mojo wouldn't be involved at all.

That might work. My concern would be 1) scattering the logic 2) extra calls to retrieve missing data eg. the event itself won't have all that you need, although this might not be that much of a problem. We'll need the events to be spec'ed properly in any case.

#9 Updated by okurz 18 days ago

  • Related to action #58184: [epic][use case] full version control awareness within openQA, e.g. user forks and branches added

#10 Updated by okurz about 19 hours ago

Also available in: Atom PDF