U4-10011 - Making guids a little more available in backoffice

Created by Claus Jensen 12 Jun 2017, 13:08:04 Updated by Shannon Deminick 17 Jul 2017, 03:25:32

Tags: Unscheduled

Subtask of: U4-9609

We've had some issues in Cloud where support (and customers) needs to find GUIDS of various entity types, which can be rather tedious to do, due to having to access the database and do SQL querys. It is possible to see the GUID of a document via the backoffice which is really convenient, but this is not the case for document types, media types, membertypes, datatypes, macros and other entities we've encountered problems with.

To make this information a little more accessible, it is now possible to hover the name input field for these entities, to see the GUID of that specific entity. This should hopefully make it a lot easier in those cases where we need to uniquely identify these (such as duplicate situations where it can be difficult to know which one is which when just looking at two duplicates in the backoffice)

Comments

Claus Jensen 12 Jun 2017, 13:08:41

PR: https://github.com/umbraco/Umbraco-CMS/pull/1995


Mikkel Holck Madsen 14 Jun 2017, 06:27:50

Merged


Niels Hartvig 14 Jun 2017, 08:17:02

Could we make this a feature that's enabled only for users with access to Developer/Settings sections? For your normal editor it would be "weird", technical information that you don't understand showing up when you hover :-)


Mikkel Holck Madsen 14 Jun 2017, 08:26:15

Its only available in the developer/settings section. Its only implemented for metadata. Content already has the info in its property tab


Niels Hartvig 14 Jun 2017, 08:57:19

Ah, beautiful :-)


Rune Strand 14 Jun 2017, 11:21:40

Awesome!!!


Nicholas Westby 14 Jun 2017, 15:59:23

I'm anticipating a usability issue with this. If it's implemented as a title attribute, the hover text will both be impossible to select/copy and will vanish in a few seconds (about 10 seconds on my computer in Chrome). Considering how long GUID's are, seems like it will be a real pain to actually get the GUID if it's in the form of a title attribute.


Niels Hartvig 15 Jun 2017, 07:19:52

@Knickerbocker it's meant for verification not for copy/pasting so it'll be unobtrusive and perfect for this purpose :)


Nicholas Westby 15 Jun 2017, 15:00:07

@hartvig Fair enough, though what about other purposes? For example, if I want to test some code by fetching a document type by its GUID? I realize that would be unwise to do in production code (as would grabbing a content node by a hard coded GUID), but for a quick test I could see doing that. Or maybe to validate something during debugging. Anywho, I don't actually need this, but just wanted to voice that there are some situations where this version of the implementation wouldn't necessarily be ideal.


Claus Jensen 15 Jun 2017, 17:36:40

If you need it for debugging or likewise, you right-click the input field, inspect and copy the value of the attribute. There's currently no good place to put this value where it is both visible and consistent across all entity types, without polluting the interface with something that ''most'' people will rarely need to know is even there.


Niels Hartvig 15 Jun 2017, 19:31:07

@Knickerbocker exactly, the point is that if we start bubbling variables like this in the interface, people might believe it's encouraged to use them so this was a good compromise. Thanks for the feedback, though!


Priority: Normal

Type: Feature (request)

State: Fixed

Assignee:

Difficulty: Normal

Category: UI

Backwards Compatible: True

Fix Submitted:

Affected versions:

Due in version: 7.6.4

Sprint: Sprint 61

Story Points:

Cycle: 2