Rudder

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.

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?

I like that last proposition.

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.

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.