Add ID to custom group/field admin forms

[mattwire]

Overview

Expose custom field/group IDs on admin forms

Before

You have to hover over URLs or inspect HTML to find out custom group/field IDs if you need them for APIs, custom integrations etc.

After

Groups:

Fields:

Technical Details

Comments

@JGaunt Can you review?

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[pradpnayak]

Looks good to me, good to merge!

[JGaunt]

Yes, this is great!

Thank you @mattwire

[eileenmcnaughton]

I think this is OK - it's an admin screen that we could reasonably expect more advanced users to use - although it's not clear it 'should' be useful to most users - @agh1 @Stoob @MegaphoneJon any resistance to this?

[agh1]

I like the principle of adding IDs. However, this isn't the only place where IDs are useful, and they appear in a handful of different ways in existing listings. While updating listings of other entities' IDs is outside the scope of this PR, we should at least be pro-active about deciding which is the best, adopt that one, and note that the others could/should be made consistent at some point.

Here are all of the possibilities I could find.

Manage Events:

Campaigns Dashboard:

Find Cases:

Manage Contribution Pages:

This PR is currently consistent with the Campaigns Dashboard. I think the main questions are

1. Column vs. note. Columns take up valuable horizontal space but are sortable. They also make the rendered display more closely match query results, which I suspect makes it easier to maintain.

2. Location and format. If a column, should it be first, second, last, or something else? If a note, what format should it be in?

[mattwire]

@agh1 Good point. Another form you didn't find is the payment processors one:

Disclaimer: I was the author of the PR that added those IDs some time ago - hence the format matching this one!

[petednz]

Support this addition. I hate having to explain to clients to hover to see what they need to see.

[petednz]

and i would vote for Column

[totten]

Another +1 for the layout as given -- with a new ID column along the left edge.

I did some quick r-run on the autobuild test site - looked good. And there's a lot of +1's on the change. IMHO, this is mergeable.

(@agh1) However, this isn't the only place where IDs are useful, and they appear in a handful of different ways in existing listings. While updating listings of other entities' IDs is outside the scope of this PR, we should at least be pro-active about deciding which is the best, adopt that one, and note that the others could/should be made consistent at some point....

Yeah, I think this PR resonates with me because the CustomField IDs are necessary for certain use-cases (eg APIs and tokens), and it's just a specific annoyance.

In the broader interest of consistency, I'd personally vote for updating "Manage Contribution Pages" and "Manage Events" to match (ie putting the "ID" column first).

But... I'd be skeptical that there is a universal "best" ID column for all views and all entities. If you consider something like "Cases", "Contacts", "Contributions", or "Activities"... the relative value of the "ID" column is more debatable (because there are lots of other columns you could meaningfully display), and the IDs take more from the visual budget (a 7-digit contact ID is ~3x wider than a 2-digit field-ID ...).

[artfulrobot]

I think this is helpful on balance, at least while there are several cases that users need to access these raw values which are tricky to find otherwise.

Would be separate PR, but horizontal space is always tight in these situations. Some of it could be freed up by replacing the long word "Enabled?" with a symbol.

I think longer term I'd prefer to see a UI that kept things really simple (no column) but revealed more info on a row click or hover (as long as it's possible to select text in the hovered box) or something, since these often aren't things you need day to day at a glance.

[agh1]

@totten and @artfulrobot bring up interesting observations about horizontal space and the relative importance of IDs.

I appreciate that IDs have varying levels of use across different entities, I think there's inherent value in consistent UI patterns: they're easier to use and easier to maintain.

I think the audience of developers here is especially sensitive to custom field ID because we use it in the API. Regular users have much more use for case ID and contact ID on a day-to-day basis.

I also am thinking that IDs are more of a "detail" than a meaningful attribute. You probably wouldn't sort by ID or scan across a table to look at IDs in the same way that you would for attributes like "enabled" or "used for". When you want the ID, you only really care about it for the one row you're looking at.

This all makes me lean toward mimicking how the cases and events are handled--with a note in the label column--rather than doing a column like campaigns and payment processors.

Long-run, I think @artfulrobot is on the right track with having a standard pop-out with ID and anything else that is nice to view from the listing but doesn't need to be a column. Maybe this could be incorporated into changes to how the links are handled at the end of each row. I also like his observation about the label "Enabled?" taking up more space than the possible values, at least in English.

[artfulrobot]

Just to add: a common(ish) use case for users needing IDs is constructing token URLs, e.g. to profiles.

[adixon]

@agh1 : actually, I always want an id column on the contribution pages listing so I can see the order in which they were created. I bet we'll find people using them more than expected, since secret codes are cool and make you feel like you understand what's going on (okay, that's my experience ...).

[magnolia61]

While debugging my own code or error logs I also use ctrl-f (find in page) quite a bit so I would opt for the colomn variant. And I love the idea for it.

[eileenmcnaughton]

I feel like the consensus is to merge as is - does anyone disagree with this take?

[artfulrobot]

I do not disagree with merging as-is. But for the record.

While debugging my own code or error logs ...

I think this does tip the balance of the UI towards developers. It will be interesting to see whether less technical users welcome the change or not.

[magnolia61]

I do not disagree with merging as-is. But for the record.

While debugging my own code or error logs ...

I think this does tip the balance of the UI towards developers. It will be interesting to see whether less technical users welcome the change or not.

:-) I understand my wording sounds the way you describe.
But this is the case for all id's already present in the backend UI.
They are both usefull for coders, and high-level implementers. End users never get to see them I guess.

[agh1]

I feel like the consensus is to merge as is - does anyone disagree with this take?

I don't feel we have consensus that as-is is the way it should look or the way other IDs should be displayed, but I don't think we're at the point of agreeing on something quickly. For that reason, I'd support merging as-is with the expectation that we might go around and standardize ID display later so it wouldn't necessarily look this way for long.

[colemanw]

Merging. Good discussion but doesn't need to take up more of people's valuable time.