Make aggregated object structure available for the end user based on rules

[erik-edling]

Description

Today it's very hard to understand and create subscription conditions since you need to know about the structure created by the rules, if you don't have access to the database it would make it even harder. In order to simplify this and make it easier to create conditions for a subscription there should be a way to show what the structure will look like based on the rules for that specific backend.

Motivation

Today it's very hard for a user of EI frontend to know exactly what the structure will look like before an aggregated object has been created and even if one exists, the user might not have access to the database to watch it.

Exemplification

Say you have an aggregated object that will look like this:

{ "id" : "a100572b-c3j4-441e-abc9-b62f48080011", "type" : "EiffelArtifactCreatedEvent", "time" : NumberLong(1473177136433), "gav" : { "version" : "1.33.0", "artifactId" : "other-system", "groupId" : "com.othercompany.otherproduct" }, "fileInformation" : [ { "extension" : "jar", "classifier" : "debug" } ], "buildCommand" : null, "TemplateName" : "ARTIFACT_1" }

The new feature would build up this structure from the rules. This would of course not be able to have any real values for each of the fields but it would provide the user with the structure things will be aggregated into.

For example with the aggregated object based on one extraction rule:
"{id : meta.id, submission: {eventId : meta.id, time : meta.time, gitIdentifier: data.gitIdentifier, submitter:data.submitter}}"

You can know that you will have a field "id" which will retrieve it's value from "meta.id". This will give the user hints about the structure the aggregated will have and the structure of where in the event the value is retrieved.

This example was only based on one rule for one event. The real implemenation would combine all rules for all events into a form that the aggregated object would take.

This "fake" object could be visible when you create subscriptions in the GUI.

Benefits

The user will have access to information regarding what the aggregated object will look like, making it much easier to create conditions.

Possible Drawbacks

Can be complicated to implement.

[e-pettersson-ericsson]

My first thought upon reading this was: wouldn't it be confusing to have both this implementation and the one discussed in #207 ?

If the main argument of this issue, is to let users familiarize themselves with writing rules and how they affect the structure of the aggregated object, then we have the Test rules page in a non production environment. In a production environment I would instead refer to issue #207 which shows actual aggregated objects already existing in the database.

In my opinion this feels dependent on #207 to exist to not confuse users who will wonder which tab to click on in the GUI. But perhaps you can enlighten me some more? I don't fully see all the benefits with implementing this issue, or rather I see more potential confusion for users which overshadows the benefits...