Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show aggregated objects in frontend GUI #207

Open
e-pettersson-ericsson opened this issue May 10, 2019 · 5 comments
Open

Show aggregated objects in frontend GUI #207

e-pettersson-ericsson opened this issue May 10, 2019 · 5 comments
Labels
enhancement New or extended features.

Comments

@e-pettersson-ericsson
Copy link
Member

e-pettersson-ericsson commented May 10, 2019

Description

We need the possibility to query an aggregated object via the frontend GUI and then visualize it for the user. I envision a separate page in the menu where the user could see a list of aggregated objects for the selected backend instance, and the possibility to view these in a pop up modal when they are clicked on.

Motivation

Instead of having to use freestyle queries using curl and get a json blob in response, it is easier for the user if it can be possible to list existing aggregated objects, and to visalize these. The visualization of the aggregated object also makes it easier to formulate queries on the object, and improves the creation of subscription conditions.

Exemplification

Let's say you have an EI frontend connected to an EI back-end. When you want to make subscriptions it helps if the aggregated objects is available to run test queries on before making subscriptions which should trigger on the aggregation.

Benefits

Querying the aggregated object would be possible to do from the GUI, enhancing the usability of EI. Having the aggregated objects available also helps when creating new subscriptions.

Possible Drawbacks

We have to consider ho many aggregations we want to visualize, and how they should be sorted. If Eiffel Intelligence has hundreds of different aggregations we can't possibly show them all per default. There should be some sort of basic types of queries which have been pre-defined to limit the number of aggregations. Perhaps have queries for a particular artifact name (artifact-rules), test case name/confidence level name (test case rules) etc, and limit the response to a few? This must be considered carefully when designing.

@e-pettersson-ericsson e-pettersson-ericsson added the enhancement New or extended features. label May 10, 2019
@e-pettersson-ericsson e-pettersson-ericsson changed the title Query aggregated objects via frontend GUI Show aggregated objects in frontend GUI Jul 2, 2019
@erik-edling
Copy link
Contributor

erik-edling commented Aug 13, 2019

I believe this is a great tool to have so that the user without any need to query or check in database(if the user even have access) can see what the aggregated objects looks like. It could be a great tool for debugging flows. This page could maybe even include other fields such as missed notifications/waitlist to enhance the debugging of flows even further.

In order to help with subscriptions i believe there should be a way to show what the aggregated object will look like based on the rules. In that way, you will get help writing your subscriptions even before any aggregated object has been created. Although this should possibly be created as it's own story(and includes implemenation in EI backend) but as it's somewhat connected i feel it to be great discussing it here as well.

@e-pettersson-ericsson
Copy link
Member Author

So then it becomes a question if the user should be able to see an actual aggregated object, existing in the database (with data) or the possibility to see an assumed aggregated object structure based on the defined rules. For example: showing how the aggregated object would look like assuming all the events come in to EI which are defined in the rules. Which one is more sought after by the user?

I like the idea of showing missed notifications you mentioned @e-edling-ericsson. Preferrably if they could be seen per subscription. Let's say a user has 4 subscriptions triggering different things. If one of them very often fails, it would be nice to see some statistics, let's say the reason why the notification failed. Or the possibility to view the last successful attempt to notify the subscriber. But that is a separate issue I believe :)

@erik-edling
Copy link
Contributor

erik-edling commented Aug 13, 2019

I think the two different "features" (see aggregated object vs see assumed based on rules) are two entirely different use cases. The first use case you proposed is a perfect way of debugging flows. In fact i think it is extremely needed if you don't have access to the database. I didn't mean those two feature to be "either this or that" but both. The second use case would be more helpful when you are creating your subscriptions and does not necessarily have aggregated objects to look at. So i think both features are needed in order to make eiffel intelligence as good as it can be 😃 I'll create another issue for that.

That seems like a great idea @e-pettersson-ericsson

@e-pettersson-ericsson
Copy link
Member Author

Sorry, I haven't had time to get back on this issue for a while (other priorities) but to sum up: this issue is about visualizing any existing aggregated object in the Eiffel Intelligence front-end GUI. The other ideas we've discussed have, from what I can see, got their own separate issues already 😄

@e-pettersson-ericsson
Copy link
Member Author

e-pettersson-ericsson commented Feb 4, 2020

A question to consider for this: how do we filter out specific aggregations to show in the GUI? What happens if the database contains hundreds of aggregations (depends on the use case for each EI instance)? We don't want to bog down the GUI because we're querying the database in the background ....

Perhaps we could have a default search which the user could select from a list. And the possibility to limit the search, to show only the 10 latest ones. Because the agrgegations will never look the same between two EI instances using different rule sets it is quite tricky to have default searches except by id.

What we do know is stored in the document is an "_id" of the document and a timestamp, the rest of the aggregation is unknown (since it varies depending on the structure set up by the rules).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New or extended features.
Projects
None yet
Development

No branches or pull requests

2 participants