MySQL Bugs: #30144: Create persistent storage for every detail on the Dashboard pages

Bug #30144	Create persistent storage for every detail on the Dashboard pages
Submitted:	31 Jul 2007 11:46	Modified:	5 Dec 2007 10:38
Reporter:	Mike Lischke	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	MySQL Enterprise Monitor: Web	Severity:	S4 (Feature request)
Version:		OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
Currently only a subset of the possible values a user can change is stored (e.g. graph settings). However, many others are not or only cookie-based (auto refresh, list limits, filters etc.). Humans like to find their work place in the same state they left it and we should support this wish.

How to repeat:
Try changing the limit on the events page, close the browser and re-open it. The setting is gone. Try setting an auto-refresh value for the monitor page, close the browser, go to another machine, open the browser and navigate to the monitor page. The settings is gone too.

Suggested fix:
- Create a persistence layer for the UI that allows to store any value a user can change, on any page, in the user preferences.
- Provide a means to reset settings to defaults (e.g. sorting, filtering, graphs etc.).
- Allow to export and import these settings so a user can quickly set up new machines to an environment he is used to.

User feedback has indicated that user accounts will be shared across multiple users and that they may access Merlin at the same time. For this reason, volatile information like search parameters should not be stored in the database or collisions are possible. What we can do is store more of this information to cookies and create more defaults that are user configurable. This has been proposed in the past and, while no objections were raised at the time, it was thought to be extremely low priority.

The question is: how often is this the case? Additionally, it is well known that such kind of account sharing can produce problems. I'd expect from an expert to know that. On the other hand limiting the user experience just because others are doing things "wrong" is not an acceptable approach for good usability. It is easy to solve the problem for "account sharers" (by creating individual accounts) if we have persistent states, but there is no way to have the "persistent workplace" other than by really saving its state.

Putting this info into cookies is a cheap trick. It solves a part of the problem instead doing it right (including import/export and across different machines). Use a different browser or clear the cookie cache and you are screwed. We already have certain values stored in the schema. It is a natural and logical step to do it for everything that is related.

Given feedback from our users and my personal experience, it is often the case that multiple users will use the same account. The only time this is predominantly not the case is when customers want more control on security constraints and security auditing. Since all of the users within one company are likely to be DBA's, differing security constraints is uncommon.

As to design for usability, you should always assume that your users are going to do the dumbest thing you can think of. Never design under the assumption that they will "do the right thing".

Regarding the utility of this bug, all applications have transient aspects. For non-transient characteristics, we currently save them to the DB or save defaults. We don't want everything to be non-transient. I believe we have chosen the right elements to be non-transient. However, the values pointed out in the first comment may benefit from having user configurable defaults (though the auto-refresh is arguable). This has been discussed in the past but determined to be low priority and no bug was opened.

My suggestion is that we do nothing for the time being and consider adding configure popups to the events and logs pages in the future.

Consider this for a later release. It was a customer request.

This bug is not scheduled to be fixed at this time.