Settings dialog options to implement

[aletson]

Dependent on #5, but I think this deserves a separate issue so that we can more easily track our unimplemented options.

• sort order
• group selection (by ID - or by API query to populate?)
• Field to use for OS detection
• Polling frequency
• Sound

[aletson]

We could set group selections in preferences too - like, expand a group of servers. Something to think about for future release.

[aletson]

We could use this to support themes.

[eburgueno]

I would add:

• Custom refresh interval
• Enable/disable playing sound

[aletson]

Sounds good. I'm going to move themes to a different milestone though since they're not nearly as important

[eburgueno]

Hi Andrew. I know we said in #5 that we would use cookies, but after thinking about it for a while and watching @glasnt presentation at the LCA2015, I got excited about the idea of simply reading our options from the URL. This has a few advantages:

1. We don't need to worry about cookies storage and their expiration.
2. URLs are transparent and easy to use.
3. Each user can still have their own version of the dashboard simply by storing their preferred URL in their Bookmarks.
4. Zabbix themselves uses this scheme.

The only disadvantage is that we need to validate the options to avoid code injection, but since the Zabbix user with API access that the end-user configures should be read-only, the security of the dashboard doesn't need to be extreme.

I started playing around this idea and just created a new branch so you can have a look at: https://github.com/eburgueno/zabbixweb/tree/feature/optionsFromURL

Of course it needs massive work, but let me know what you think before I continue down the rabbit hole.

[aletson]

Seems pretty neat. I think we could definitely do something like that. That library you're using looks like it can return a JSON object for URL parsing which I think would make it really easy to extract stuff we need.