search

ohmage / gwt-front-end

The javascript/GWT code behind the front end.
6 stars 2 forks source link

improve audit log view and functionality #255

Closed jshslsky closed 8 years ago

jshslsky commented 12 years ago

@stevenolen @hongsudt need to brainstorm a good design for what this feature should be, e.g., what are the use cases that are the most important? Then we can run this by @ideasphere and @jojenki for implementation.

@stevenolen can you lead this brainstorming effort for now?

stevenolen commented 12 years ago

Additions to the audit log page:

Limiters and search at the top: -Date Range instead of single day. dropdown selectors with calendar view? Defaults to range of today. -Timestamp range. Allows further limiting of range, although I'm not sure visually what is the best way to present this… -Search functionality. Search on all columns in audit log, but most importantly user_id and class. -the "only failures" check box is good. while we have: successes, failures and successes+failures, we really only need to be able to show all or limit by failures. this may not be necessary if filters for columns can be accomplished (see 2nd point below).

Table changes, additions: @jojenki: can some of these be done? in particular, the json strings? -The fields that would make the audit log really good are: timestamp, user_id, client type (android, browser), API used, response status (success/failure) and class. -The columns should be "click to sort by" and even some filter functionality for certain columns if possible (the dropdown would show all different data options available within the column below, and allow the user to check or uncheck to show/hide that data from the list). -last column of each item has a "…" button (this could also be implemented by clicking the item) which shows all information that can be dragged up regarding the item: json request, response from server, server code etc.

jojenki commented 12 years ago

The server returns all of this information except the class. The class would be tricky because we would probably have to save alot of state to do it the way people would expect it.

For example, if someone was in classes A, B, and C when they made a request and, at some later date, was removed from class C and added to class D, then what would be the expectation when viewing this information? Would you expect to see class C or class D.

If it's class C, then we would need to save all of the classes that the user is in every time they made a request.

If it's class D, then maybe a more eloquent way to handle it would be some sort of composite information on the front end. The front end may already have this information or could query it. I'm not sure, but it seems like this is not the expected behavior.

stevenolen commented 12 years ago

Whoa...totally makes sense. What if we used campaign instead of class? With campaign I wouldn't necessarily be thinking of "what campaigns the user is participating in" but more "what campaign is this api call directed at"...with certain entries in the log I assume that campaign wouldn't exist, but that field could just be null, right? Is that something that's more manageable? I'm definitely only looking for extra info in the audit log that can be drawn from existing data sources, so keep that in mind.

jshslsky commented 12 years ago

@stevenolen can you provide a link here to your image?

stevenolen commented 8 years ago

this repo is now deprecated, closing!

the ohmage 2.x admin tool is available here: https://github.com/mobilizingcs/admin