action #58304

A personal activity view for developers

Added by coolo 6 months ago. Updated about 1 hour 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... Blocked 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 5 months ago

  • Description updated (diff)

#2 Updated by okurz 5 months ago

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

#3 Updated by mkittler 4 months 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 4 months ago

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

#5 Updated by mkittler 4 months 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 4 months 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 4 months 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 4 months 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 4 months 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 4 months ago

#11 Updated by cdywan 15 days ago

Another feedback conversation brought up the value of live updates, as you're looking at the list and expecting to see the current state when you get back to it. Notifications would even further optimize the use case of checking a finished job for the results.

openqa-mon is implementing a CLI version of that in a simple script.

#12 Updated by okurz 15 days ago

nice idea. Would be cool to have this software available in public form.

EDIT: Talked to the author, it's public: https://github.com/grisu48/openqa-mon \o/

#13 Updated by cdywan 9 days ago

  • Status changed from New to In Progress
  • Assignee set to cdywan
  • Target version set to Current Sprint

I've been coming back to this ticket on and off to collect user stories and actually started looking into a proof of concept for the rendering on the Javascript side, so I might as well take it.

#14 Updated by okurz 9 days ago

I am wondering about your pick. The ticket is not properly refined, was not in "Current Sprint" and "Normal" priority. If you really fancy doing it, I can't stop you but it isn't exactly "following priority", right? :)

EDIT: Discussed with cdywan. We agreed to conduct a time boxed feasibility study with 4h to find out what is possible, how to continue, what is the expected outcome and effort.

#15 Updated by cdywan 7 days ago

So some notes on this:

  • A look at the code revealed some inconsistencies between single and multiple event rendering, and missing CSS to make the indentation that the code already applies work: os-autoinst/openQA#2875
  • With the audit log having the basics to render events, which right now means formatting JSON, and having the ability to filter by any database column, we could add more formatters based on events types in Javascript (what Marius suggested before) and I think that seems the best option if we can re-use that code in several places
  • it would be easy to add other routes e.g. /activity with different columns, and a default filter
  • we could have a different route e.g. /group_activity which repurposes this not as a personal view but for a particular group - not the scope of this ticket strictly speaking, but this would cover more use cases and make it useful to a wider audience
  • meaningful changes can't easily be identified e.g. jobgroup_update includes all properties available, not just new values - this comes from the HTML forms, I think we'd want to fix that so that the formatter can just show what happened, by omitting values from the event that did not change
  • I was surprised to find that job_done is blacklisted. Apparently this is considered clutter. We probably want to re-consider that to get job results. De-duplication could be applied here also to make it more useful. We could also add filters for different views instead of blacklists, technically speaking this is easy to enable. We can incidentally add hidden columns and allow searching them - this was not clear to me before.

#16 Updated by cdywan about 1 hour ago

  • Status changed from In Progress to New
  • Assignee deleted (cdywan)
  • Target version deleted (Current Sprint)

Resetting the status. Findings from my above time-boxed study should be evaluated to refine and possibly split up the ticket.

Also available in: Atom PDF