Allow and save column selection for search results

[markcraig]

As a user, I'd like to be able to choose the columns to display in the search results table, and I'd like the app to remember my choice.

The column names to select could be taken from the attribute type names in actual search results.

[markcraig]

The DS evaluation defines a json attribute and associated object class:

# Schema definitions for "json" attribute and auxiliary object class
attributeTypes: ( json-attribute-oid
  NAME 'json'
  SYNTAX 1.3.6.1.4.1.36733.2.1.3.1
  EQUALITY caseIgnoreJsonQueryMatch
  X-ORIGIN 'DS Documentation Examples' )
objectClasses: ( json-object-class-oid
  NAME 'jsonObject'
  SUP top
  AUXILIARY
  MAY ( json )
  X-ORIGIN 'DS Documentation Examples' )

The UI could use the attribute to save settings on the user entry. It might be a nice way to save searches as well, for example.

The settings could be accessible through the search UI and also in the settings page, https://github.com/markcraig/hdap-demo/blob/main/src/pages/settings.vue.

[markcraig]

For this to work, the table in https://github.com/markcraig/hdap-demo/blob/main/src/pages/search.vue needs to be generic, or nearly so. The UI should "know" how to render CREST-specific fields like _id and _rev, but not attributes defined in the LDAP schema, like cn, json,manager, postalAddress, or mail, because the LDAP schema is up to the user.

The UI sometimes needs extra information to properly format field content, information which might be in the JSON schema:

• For cn or json, the UI doesn't necessarily need to read the schema. It can show an array of strings as a comma-separated list and JSON as its stringified representation, for example.
• For manager, the UI needs to know the values should be links. The information is in the schema: "format" : "json-pointer". In order to discover the schema for manager, the UI needs to get the schema for a resource with a manager field. AFAIK, HDAP doesn't provide a means to request the schema for a field or list of fields.
• For postalAddress, an array of arrays of strings, the UI could maybe uncover the structure, but it would probably be easier to do so with the schema.
• For mail, the schema only indicates its value is an array of strings. It doesn't seem straightforward to know that it's an array of email address strings, which could be formatted as mailto: links.

[matthew-swift]

It's true that mail address is simply defined as a string in RFC 4524. I wonder if we should include hints in our standard schema elements for attributes like this? For example, we could define an X-PATTERN extension constraining the set of allowable values.

Regarding manager, this attribute uses the distinguished name syntax whose JSON schema is json-pointer as you correctly point out. These attributes will need a special renderer / editor allowing users to find and select the entries - a popup dialog? Note that it will need to share some UI elements from the rest of the application which already has UI for searching and selecting entries.

[markcraig]

I forgot I had documented this form of access to schema elements:

curl --insecure 'https://localhost:8443/hdap/schemas/attributeTypes/manager' 
{"_id":"manager","type":"array","uniqueItems":true,"items":{"type":"string","format":"json-pointer"}}

[markcraig]

The X-PATTERN extension sounds good, and it ought to work in many cases. How does the application know that $ in postalAddress means newline?

For editing json-pointer attributes, I imagine an autocomplete selector that somehow has good performance even when there are lots of possible completions. For example, when you type dc=com/dc=example/ou=People/ in the autocomplete field for the default DS evaluation profile. Would setting the autocomplete's one-level search with a page size of 10, for example, keep latency low enough?

No doubt client apps like the UI will just need to "know" that a very fields such as userPassword require special handling.

[markcraig]

Completely failing to figure out how to make the data table cells generic, yet keep rows selectable. The really tricky bits with this at my present lack of understanding are being unable to formulate search terms even after reading doc, and being unable to understand enough doc at a time to put things together on my own.

[markcraig]

Going to unassign myself for now.

I've spent days now failing to understand or find examples on how to uncouple the data table columns from the template used to format the table. I also don't see another way of making columns optional. So I'm blocked.