[REQ] Environment warning signs

[GoogleCodeExporter]

Can we please have the ability to set a particular connection such that it 
shows big ugly warning signs on the window for that connection?  I have a 
live and a test server with open connection to each, it'd be nice if the live 
window had big yellow-and-black stripes on it or something to show that it's 
a dangerous server.  That, or perhaps we can set a "read-only" to be sure no 
inserts or updates or deletes or alters get executed?

Ta,

Original issue reported on code.google.com by kevin.li...@gmail.com on 29 Jul 2009 at 10:53

[GoogleCodeExporter]

We get a surprising amount of requests for this, so we'll try and jam it in 
soon.

For the time being, note that the connection name is displayed in the window 
name so a nice long warning name 
with lots of capitals may be a small visual clue :)

Read-only is an interesting idea but probably harder to implement/restrict, 
especially with custom queries - you 
may want to set up restricted users with read-only access to the remote 
databases instead.

Original comment by rowanb@gmail.com on 29 Jul 2009 at 11:13

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by stuart02 on 1 Aug 2009 at 11:17

• Added labels: Component-UI, Milestone-Release0.9, Priority-Medium, Usability

[GoogleCodeExporter]

Original comment by stuart02 on 16 Nov 2009 at 2:58

• Changed title: [REQ] Warning signs

[GoogleCodeExporter]

Original comment by stuart02 on 1 Mar 2010 at 4:51

• Changed title: [REQ] Environment warning signs

[GoogleCodeExporter]

even something as simple being able to set the font color for the window title 
would be 
a big help (i.e. red window title text for prod, orange for staging and black 
for local) ...

Original comment by dan.acke...@gmail.com on 2 Mar 2010 at 8:01

[GoogleCodeExporter]

One possible solution quick mockup

Original comment by schlabbe...@gmail.com on 8 Mar 2010 at 1:42

Attachments:

• ui-marked.png

[GoogleCodeExporter]

Absolutely not.  

Original comment by mainstre...@gmail.com on 8 Mar 2010 at 2:06

[GoogleCodeExporter]

mainstreetmark: at the mockup? If so, why not?  This would very much be an 
option - a way of distinguishing 
certain windows, almost certainly production windows easily confused with dev 
environments.

The other way of approaching this is a "locked" window which prevents changes, 
but I can see situations where 
people would want changes allowed, but clearly distinguished.

Original comment by rowanb@gmail.com on 8 Mar 2010 at 2:24

[GoogleCodeExporter]

mainstreetmark, also realise that that's just a mockup. not necessarily a final 
colour or anything.

Original comment by avenja...@gmail.com on 8 Mar 2010 at 2:42

[GoogleCodeExporter]

I understand the mockup aspect, as well as the need.  But changing the color of 
the menubar is a violation of 
system-wide window behavior and appearance.  Leave the window to the OS, and 
change the appearance of the 
content.

Original comment by mainstre...@gmail.com on 8 Mar 2010 at 4:05

Attachments:

• sqlp.png

[GoogleCodeExporter]

Another three mockups

Right beneath the toolbar will probably not be an option as we probably want to 
use that area with transactions.

Original comment by schlabbe...@gmail.com on 8 Mar 2010 at 10:51

Attachments:

• [Bild 5-3.png](https://storage.googleapis.com/google-code-attachments/sequel-pro/issue-346/comment-11/Bild 5-3.png)
• [Bild 5-2.png](https://storage.googleapis.com/google-code-attachments/sequel-pro/issue-346/comment-11/Bild 5-2.png)
• [Bild 5-1.png](https://storage.googleapis.com/google-code-attachments/sequel-pro/issue-346/comment-11/Bild 5-1.png)

[GoogleCodeExporter]

I like the "Lock" concept.

Original comment by mainstre...@gmail.com on 9 Mar 2010 at 1:52

[GoogleCodeExporter]

I'd not only like to second (or third?) this request, but extend it a tiny bit 
further - it would be great to have 
the option for multiple indicators/colors, i.e. red for production, yellow for 
dev/staging, normal behavior for 
local, etc.

I prefer the mockup in comment #10 as it's not unlikely to have the bottom of 
the window stuck off the 
bottom of the screen so mockup 5-3 in comment 11 would be less effective. To 
me, it's worth "wasting" a 
little screen/window real estate with the added height of a warning strip if it 
stops me from doing something 
stupid in production (doubly so as I've been known to edit a copy of my prod db 
locally so my DB names can 
be misleading)

Original comment by firehed on 13 Apr 2010 at 4:18

[GoogleCodeExporter]

Issue 637 has been merged into this issue.

Original comment by stuart02 on 14 Apr 2010 at 4:14

[GoogleCodeExporter]

#10 is easily the best so far, and the most "Mac-like" IMHO. Whatever visual 
cue is used here, it needs to be 
clearly and constantly visible in ALL views for that particular connection. If 
it's too subtle or placed anywhere not 
immediately and constantly visible, it's useless.

The placement in that mockup is also close to optimal. Regarding #11 about the 
transaction area: just have the 
warning strip appear above or below the transaction area, then. The small extra 
sacrifice of horizontal space in 
the content area is quite acceptable.

Original comment by jarkko.l...@gmail.com on 23 Apr 2010 at 7:55

[GoogleCodeExporter]

How about a blue/red ribbon like the one from the attached screenshots?

Original comment by ursache....@gmail.com on 29 Apr 2010 at 9:01

Attachments:

• [blue ribbon.png](https://storage.googleapis.com/google-code-attachments/sequel-pro/issue-346/comment-16/blue ribbon.png)
• [red ribbon.png](https://storage.googleapis.com/google-code-attachments/sequel-pro/issue-346/comment-16/red ribbon.png)

[GoogleCodeExporter]

Issue 684 has been merged into this issue.

Original comment by stuart02 on 13 May 2010 at 5:50

[GoogleCodeExporter]

Issue 711 has been merged into this issue.

Original comment by stuart02 on 28 May 2010 at 1:14

[GoogleCodeExporter]

Read-only mode would be a blessing.

Original comment by dusan.ma...@gmail.com on 16 Jun 2010 at 1:54

[GoogleCodeExporter]

set up database-specific connection privileges for a read-only mode.

Original comment by mainstre...@gmail.com on 16 Jun 2010 at 3:21

[GoogleCodeExporter]

Another idea: We could change the background color for the table list column.

Original comment by schlabbe...@gmail.com on 12 Aug 2010 at 3:38

[GoogleCodeExporter]

I'd love the ability to lock/unlock read-only on a particular connection. 
Visually it could be a padlock in the toolbar, like on OSX Preferences.

I agree that making a read-only user makes a lot of sense, but in my case I do 
want to write changes. Sometimes, I have two different connections with two 
different users, but switching between them is a bit clunky. A big aspect of 
this is a lack of visual queues.

Perhaps, for each connection, there can be multiple sets of MySQL credentials. 
Sequel Pro would need no other logic than provide a convenient switch to 
disconnect and reconnect as the new user. By default, I would connect to a live 
db as a read-only user and then switch if I need to make a change.

Original comment by emsp...@emspace.com.au on 3 Sep 2010 at 3:50

[GoogleCodeExporter]

Issue 827 has been merged into this issue.

Original comment by stuart02 on 19 Sep 2010 at 5:42

[GoogleCodeExporter]

Issue 831 has been merged into this issue.

Original comment by stuart02 on 21 Sep 2010 at 8:44

[GoogleCodeExporter]

Issue 741 has been merged into this issue.

Original comment by stuart02 on 5 Nov 2010 at 9:21

[GoogleCodeExporter]

Issue 921 has been merged into this issue.

Original comment by stuart02 on 6 Dec 2010 at 6:37

[GoogleCodeExporter]

Just thought I would chime in here.

#10 is a good idea, and looks compelling but the way I read that is it only a 
binary option, it's there or it isn't. I think it would be much more flexible 
to use icons/colors in some way as the user can choose among any number of 
visual alert options. Groups could be colored also with the option of coloring 
the children.

#11 5-2 The lock option could be helpful but does not convey any real meaning 
beyond that updates, etc, are locked. If you want a locked connection, lock the 
user IMHO.

#11 5-1 I think would be the easiest to do, conveys more meaning, takes up no 
screen real estate and offers the most flexibility to the user. User controlled 
icons for the connections and groups would be a nice addition to the fav tree 
and tabs.

Visual cues (color/icons) tell the user to wake up because they are root or 
production and/or what machine/group they are in, etc.

Original comment by emptyvee on 12 Dec 2010 at 9:35

[GoogleCodeExporter]

Issue 955 has been merged into this issue.

Original comment by stuart02 on 20 Jan 2011 at 8:05

[GoogleCodeExporter]

A "mostly read-only mode" would still be a very worth-while feature.

That is, Sequel Pro itself blocks operations it knows to be write (such as 
selecting and typing into a cell value, or dragging columns around in Structure 
tab), but might miss some (like complicated queries with embedded updates in 
Query window).

Original comment by repennin...@gmail.com on 24 Sep 2011 at 12:13

[GoogleCodeExporter]

Wouldn't it be worthwhile to break apart the "big ugly warning signs" item from 
the "read-only mode" item?

Granted, they come up in much the same contexts, and help assuage the same 
fears. But they're really not addressing the same user stories, and of course 
their implementations would be utterly different.

Original comment by repennin...@gmail.com on 24 Sep 2011 at 12:21

[GoogleCodeExporter]

As I'm sitting here waiting for an absurdly slow query to run against 
production, I had a completely different thought on implementation based on 
context:

There are limited places where you can actually modify data, so it makes sense 
to limit where a warning would be displayed (so it's not constantly there, and 
eventually gets ignored). Context menu hover states (ex. right clicking a table 
and highlighting 'drop table') and the query editor - in effect, only places 
where clicking your mouse button or hitting return will modify data. Rather 
than a constant stripe across the connection's window at all times, it would 
just change the hover color on context menu elements or buttons (ex. add row to 
table) from the standard system blue to that warning red/yellow stripe (and 
maybe a paler version as the query editor background).

I'm sure that kind of thing is a massive HIG violation, but that's also kind of 
the point of a warning indicator - make it look out of the ordinary.

Hopefully that was explained reasonably well, but I could probably mock 
something up if people like the concept.

Original comment by firehed on 24 Sep 2011 at 12:41

[GoogleCodeExporter]

Here's an refined version of comment #10.

 - It's visible in all modes. 
 - It's visible even in fullscreen in Lion
 - It's still visible if tabs are hidden
 - It could potentially have various colours. Perhaps those used by the system for labelling files/folders

Original comment by avenja...@gmail.com on 26 Oct 2011 at 10:23

• Added labels: Milestone-Release1.0
• Removed labels: Milestone-Release0.9

Attachments:

• enviro.png

[GoogleCodeExporter]

> #31: it makes sense to limit where a warning would be displayed (so it's not 
constantly there, and eventually gets ignored).

Tricky, in that you have to be sure you get all the places. The offered list in 
that comment, for instance, is missing at least one stunningly critical spot: 
the Structure tab is modifiable in many ways, including at least one not listed 
in the general gesture list there: dragging a field name in Structure can 
actually ALTER TABLE to change the order of the columns, which can break 
existing code that depends on column order (such as INSERT or UPDATE without 
explicit field names).

Original comment by repennin...@gmail.com on 26 Oct 2011 at 5:47

[GoogleCodeExporter]

Several commenters have suggested setting up a connection with a read-only 
user, to handle the "prevent modifications." This would work, of course, but 
it's very awkward for the "read mostly" case. That is, I believe it's pretty 
common (certainly, I'm in this position often) to connect to a database that 
should not be modified lightly to browse safely (accidental changes blocked), 
find a spot that actually does require modification, and then want to change 
something so I can make the tweak. Changing to a completely different 
connection disrupts context (which table am I looking at? have I filtered it to 
spot the errant entry? what browsing and query history have I accumulated to 
get here?).

This seems closely analogous to the OS X System Preferences needs and behavior. 
For example, I can enter the "Users & Groups" SysPrefPane and read my own 
settings and the Login Options settings. But if I want to check "Allow user to 
reset password using Apple ID" (for example), I have to "click the lock to make 
changes."

Original comment by repennin...@gmail.com on 26 Oct 2011 at 5:54

[GoogleCodeExporter]

SQLyog are coloring the tab for the connection. That works pretty well.

Original comment by k...@greenwire.co.uk on 5 Jan 2012 at 3:36

[GoogleCodeExporter]

Issue 1271 has been merged into this issue.

Original comment by stuart02 on 12 Feb 2012 at 11:23

[GoogleCodeExporter]

Keep it simple - Always show a tab, and let us chose a color for the tab.

If you insist on hiding the tabs when there is only one (bad idea), then let 
the color also be shown as the background color the tree (left part of the 
window).

Original comment by l...@ordo.dk on 22 Feb 2012 at 2:40

[GoogleCodeExporter]

Please prioritize this. :-/

Attached is how SQLyog does it

Original comment by kasperha...@gmail.com on 22 Feb 2012 at 2:40

Attachments:

• sqlyog_colouring.png

[GoogleCodeExporter]

Issue 1287 has been merged into this issue.

Original comment by schlabbe...@gmail.com on 13 Mar 2012 at 11:30

[GoogleCodeExporter]

Original comment by abhibeck...@gmail.com on 24 Mar 2012 at 1:09

• Added labels: Milestone-ReleaseFuture

[GoogleCodeExporter]

You don't have to block every potentially-writing query, in my opinion. Just 
remove the ability to edit cells in table views, and change the colour of 
something, anything. If you're completely against changing part of the window 
itself, I think the attachment of #32 is completely fine.

In the meantime, I guess I should look into this sqlyog thing?

Original comment by mich...@uken.com on 28 May 2012 at 8:15

[GoogleCodeExporter]

SQLyog is for windows only.

All we really want, is a way to color the background of the table lane 
depending on server.

Original comment by k...@greenwire.co.uk on 29 May 2012 at 8:00

[GoogleCodeExporter]

Maybe it is a good idea to have a "background color selector" in a favourites 
editor? This will solve this "issue" with ease.

Original comment by skinny.b...@gmail.com on 23 Aug 2012 at 3:08

[GoogleCodeExporter]

Issue 1480 has been merged into this issue.

Original comment by schlabbe...@gmail.com on 11 Oct 2012 at 6:31

[GoogleCodeExporter]

I could settle for a #43 "background color selector in favorites" feature (or 
select any other visual distinguisher, such as the #16 sash, or the #10 Max 
Headroom Banner, or others).

Original comment by repennin...@gmail.com on 11 Oct 2012 at 6:42

[GoogleCodeExporter]

My mockups are not that different from some above, but still I add them just in 
case. I made them when issuing a duplicate before noticing this one already 
existed.

The idea is to be able to select among different patterns/colors, as one may 
want to distinguish between more than just "production or not".

http://sequel-pro.googlecode.com/issues/attachment?aid=14800000001&name=banner1.
jpg&token=O1G63XYDGWi5zdtFpW5m0f5wx24%3A1350027722073&inline=1
http://sequel-pro.googlecode.com/issues/attachment?aid=14800000000&name=banner2.
jpg&token=8O1KRrRa2zul-r3qHm6aDfzuF0A%3A1350027722073&inline=1

Original comment by elmi...@gmail.com on 12 Oct 2012 at 7:50

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I vote for #42+. Please add an option for setting a background color of the 
table lane in favorite settings.

Original comment by filip.li...@gmail.com on 21 Jan 2013 at 11:05

[GoogleCodeExporter]

Issue 1622 has been merged into this issue.

Original comment by stuart02 on 14 Feb 2013 at 10:26

[GoogleCodeExporter]

[deleted comment]