Closed jortizcs closed 11 years ago
@metromoxie You've been messing with the views, you think you could look into this?
Sure, I suppose I can do that. I could use some pointers, though. Like, do we currently actually have a concept of reports? I thought that we hadn't actually implemented that yet. And should we just be counting the number of alarms at the moment and displaying that?
We don't yet have the concept of reports... but for now we can use the table "data". Each entry is in the form (id, username, filepath, ts). Yes I think the dashboard can just display each entry plus the number of alarms and a link that redirects to the corresponding chart.php?user=X&id=Y
A report is the set of all alarms associated with a file.
Who's taking care of this bug? It's still open and unsolved. @mh2012 You might to take a look here. It's an issue we're blocking completion on.
@metromoxie @romain-fontugne As I mentioned, of course we have a concept of reports. A report is generated per file. Note my earlier comment (from several weeks ago).
@metromoxie Joel, it's taking me too long to figure this out, this is a blocker right now. Can you take care of this since it will be quick for you to figure this out? Basically we just need to display all reports in that table.
Sure, I'll take a look at it.
@jortizcs A clarification. In the SBS MySQL DB, the ID column for alarms seems to not be unique for alarms. That is, at least in the example you gave me, both of the alarms have id '1'. I assume, then, that this maps to the IDs in the 'data' table.
This is important, because what I'd love to do, is go through the data table, extract all the rows where the user is the current user, and then take the ID in that row and search for all alarms with that ID. Is that an accurate way of doing this?
I just pushed a new branch "dashboard-dyn" that I think has a basic working dynamic dashboard. @jortizcs and @romain-fontugne, can you check it and make sure it looks the way you expect it to? This is particularly relevant as I implemented it with the assumption that the IDs in the "alarms" table map to the "IDs" in the "data" table.
Obviously, things aren't pretty, and we haven't implemented things like "Tags" and "Severity" yet, but I just want a basic sanity check on what I'm putting into the tables.
Once you've given me the LGTM, I'll merge it into dev-anomaly.
Yes the 'ID' column maps to the one in the 'data' table. I also was a bit confused about that... We should probably change the column name to a more explicit one and add a unique id for the alarms...
I'll checkout your branch later today or tomorrow and let you know how is it.
Sweet, thanks! That gives me a bit more confidence in my solution, though :-)
On Mon, Apr 29, 2013 at 7:14 PM, romain-fontugne notifications@github.comwrote:
Yes the 'ID' column maps to the one in the 'data' table. I also was a bit confused about that... We should probably change the column name to a more explicit one and add a unique id for the alarms...
I'll checkout your branch later today or tomorrow and let you know how is it.
— Reply to this email directly or view it on GitHubhttps://github.com/jortizcs/Pangia/issues/3#issuecomment-17206236 .
Looks good to me! I just have a bunch of "got res!" displayed in the console but it does the job :-)
well.. it would be great to order the reports by date (the latest one first)
Good call about the "got res." It's removed. Also, I've now made the columns sortable when you click on them, although I need to add some icons for that. I'll open a new ticket for that.
On Wed, May 1, 2013 at 2:22 AM, romain-fontugne notifications@github.comwrote:
well.. it would be great to order the reports by date (the latest one first)
— Reply to this email directly or view it on GitHubhttps://github.com/jortizcs/Pangia/issues/3#issuecomment-17274315 .
The dashboard is currently static and has broken links. It should update to reflect the anomalies found in each of the files submitted.