Project

General

Profile

Actions

User story #2540

closed

Make event log display human readable

Added by Jonathan CLARKE almost 12 years ago. Updated over 11 years ago.

Status:
Released
Priority:
N/A
Assignee:
Jean VILVER
Category:
Web - Maintenance
Target version:
UX impact:
Suggestion strength:
User visibility:
Effort required:
Name check:
Fix check:
Regression:

Description

Currently, event log details are displayed in a technical, non formatted way. For example:

Clearly, we can not release Rudder 2.4.0 in this state.

I'm opening this issue to enable discussion as to how we can solve this issue. I have a few questions, to understand what is possible (easily, without rewriting the whole webapp):
  1. Can someone fix the ** indendation problem on bullet points once and for all? (they have negative indendation and go off the left of the "text area", for those that haven't noticed)
  2. Is it possible to design and implement a specific "display template" for each type of change? Ie, one nice template for "DirectiveAdded", another for "DirectiveModified", another for "RuleAdded", etc?
  3. Could these display templates include several tabs, to display different levels of detail? For example "Metadata", "Directive variables" (human readable), "Directive variables (raw)" (XML)?
  4. Can you build a simple system where the technical names "DirectiveAdded", "DirectiveModified", "RuleAdded", etc are looked up in a key/value dictionary (ie, a properties file?) and the technical names are replaced with nice human readable ones? (ie, in this case something like "Directive added"?)

Assigning to François for the questions, but I think several people will have to work on the implementation :)


Files

cap.png (34.6 KB) cap.png Jonathan CLARKE, 2012-06-06 23:40
event-log.png (12.9 KB) event-log.png Jean VILVER, 2012-06-11 15:38

Subtasks 5 (0 open5 closed)

Bug #2569: Fix indendation problem on bullet points with HTML listReleasedJean VILVER2012-06-12Actions
Architecture #2570: Put all types of event for events log in a key/value dictionary (a properties file)ReleasedJean VILVER2012-06-12Actions
Architecture #2571: Design multiple templates for all event types in events logReleasedJonathan CLARKE2012-06-12Actions
Architecture #2572: Implement templates for all event types in events logReleasedJean VILVER2012-06-12Actions
User story #2577: Swap description and reason column in Event LogsReleasedJean VILVER2012-06-12Actions

Related issues 1 (0 open1 closed)

Related to Rudder - User story #1686: In log events, display names of items in place of UUIDsReleased2011-09-05Actions
Actions #1

Updated by François ARMAND almost 12 years ago

Answer to the question with some weight.

Jonathan CLARKE wrote:

1. Can someone fix the ** indendation problem on bullet points once and for all? (they have negative indendation and go off the left of the "text area", for those that haven't noticed)

I don't know. I believe it can't be really solved at the top level, because it would cause all the Rudder main CSS to break appart.
Jean will look to it.

2. Is it possible to design and implement a specific "display template" for each type of change? Ie, one nice template for "DirectiveAdded", another for "DirectiveModified", another for "RuleAdded", etc?

Yes.
It's relatively easy to do (a couple of hour if I remind correctly), what takes a lot of time is designing and implementing each of these template. I can't really set an estimation for each template, because for course it depends of the template. But a couple of hour by template seems to be a lower bound.

3. Could these display templates include several tabs, to display different levels of detail? For example "Metadata", "Directive variables" (human readable), "Directive variables (raw)" (XML)?

Yes, I don't see any technical limitation for the content of the details. Perhaps some arcane JS conflicts between the the grid and what it contains, but nothing else a priori.

4. Can you build a simple system where the technical names "DirectiveAdded", "DirectiveModified", "RuleAdded", etc are looked up in a key/value dictionary (ie, a properties file?) and the technical names are replaced with nice human readable ones? (ie, in this case something like "Directive added"?)

Yes. That should be a couple a minutes.

Actions #2

Updated by François ARMAND almost 12 years ago

  • Status changed from New to Discussion
Actions #3

Updated by Jean VILVER almost 12 years ago

  • Assignee changed from François ARMAND to Jean VILVER
Actions #4

Updated by Jean VILVER almost 12 years ago

Jonathan CLARKE wrote:

4. Can you build a simple system where the technical names "DirectiveAdded", "DirectiveModified", "RuleAdded", etc are looked up in a key/value dictionary (ie, a properties file?) and the technical names are replaced with nice human readable ones? (ie, in this case something like "Directive added"?)

It's seems like the information you need is already there, but maybe not in the correct order (in the Description column) :

In EventListDisplayers.scala (com.normation.rudder.web.services), there is a match-case that manage the Description column. Isn't the best solution is to use the same way to manage the Event Type column rather than a properties file?

And, among these examples, what result is expected :

Example 1 (actual, which I prefer) :
Event Type : RuleDeleted
Description : Rule fooRule deleted

Example 2 (with a match-case or a properties file) :
Event Type : Rule Deleted
Description : Rule fooRule deleted

Example 3 (with a match-case or a properties file) :
Event Type : Rule fooRule Deleted
Description : Rule fooRule deleted

Actions #5

Updated by Jonathan CLARKE almost 12 years ago

Jean VILVER wrote:

Jonathan CLARKE wrote:

4. Can you build a simple system where the technical names "DirectiveAdded", "DirectiveModified", "RuleAdded", etc are looked up in a key/value dictionary (ie, a properties file?) and the technical names are replaced with nice human readable ones? (ie, in this case something like "Directive added"?)

It's seems like the information you need is already there, but maybe not in the correct order (in the Description column) :

You have a good point. These two columns seem to have a lot of information duplicated.

In EventListDisplayers.scala (com.normation.rudder.web.services), there is a match-case that manage the Description column. Isn't the best solution is to use the same way to manage the Event Type column rather than a properties file?

Well, the advantage of using a properties file is that a non-technical person can change the display names, without having to learn Scala :) It's a common practice to separate logic from variables/data.

And, among these examples, what result is expected :

Example 1 (actual, which I prefer) :
Event Type : RuleDeleted
Description : Rule fooRule deleted

Not this one, as it displays technical data ("RuleDeleted" is not an English word, it's a technical variation of one) and the WebUI is supposed to be easy to use and understand.

Example 2 (with a match-case or a properties file) :
Event Type : Rule Deleted
Description : Rule fooRule deleted

Example 3 (with a match-case or a properties file) :
Event Type : Rule fooRule Deleted
Description : Rule fooRule deleted

These two examples made me realize a fourth option that I think I prefer:

Event Type: Rule Deleted
Object: fooRule

What do you think about this one?

Actions #6

Updated by François ARMAND almost 12 years ago

I like that last proposition.

Actions #7

Updated by Jean VILVER almost 12 years ago

For Rule deletion, one word in object ('fooRule') seems OK. But, it won't be for every different type of events.

I would suggest these kind of logs (2-words type and a short details/description sentence) :

Type: Rule Deleted
Details: fooRule has been deleted.

Type: User Login
Details: The User 'jon.doe' logged in.

Type: Successful Deployment
Details: Rudder succesfully deploy the application.

Actions #8

Updated by François ARMAND almost 12 years ago

  • Target version changed from 2.4.0~beta1 to 47

That task can't go to 2.4.

re scheduled for 2.5.

Actions #9

Updated by Jonathan CLARKE over 11 years ago

  • Target version changed from 47 to 50
Actions #10

Updated by Jonathan CLARKE over 11 years ago

  • Target version changed from 50 to 2.4.0~beta3
Actions #11

Updated by Jean VILVER over 11 years ago

  • Status changed from Discussion to Pending technical review

I think we have a pretty good result for 2.4~beta3. So I'm changing the state of this ticket to Technical Review.

Actions #12

Updated by François ARMAND over 11 years ago

  • Status changed from Pending technical review to In progress

Jean, which are the relevant commit for that ?

Actions #13

Updated by Jean VILVER over 11 years ago

François ARMAND wrote:

Jean, which are the relevant commit for that ?

There is not a relevant commit, but multiple commits which can mainly be found in the #2572 subtask of this ticket.

Actions #14

Updated by Jean VILVER over 11 years ago

  • Status changed from In progress to Pending technical review
Actions #15

Updated by François ARMAND over 11 years ago

  • Status changed from Pending technical review to 10

Close that one, it can't really be put forward as it is and need more detailed specification on a case by case basis.

Actions #16

Updated by Jonathan CLARKE over 11 years ago

  • Status changed from 10 to Released
Actions

Also available in: Atom PDF