manthey
commented
4 years ago This can be implemented in stages (each of which can get its own issue and PR when it gets worked on).
-
[x] Create a new panel that would appear between Zoom and Annotations for "Metadata". It would be closed by default and indicate if there was metadata present (perhaps by showing the first key/value in a small font after the title). The panel itself would have the metadata much like the Girder Item view (hopefully we can reuse the metadata widget).
-
[x] Define a schema for how to expose metadata. Pick a storage location. When such a schema is present, only show relevant metadata (the schema should allow regex key options) in the panel. Creating new metadata would be restricted and validated according to the schema (though would never remove existing metadata outside of the schema).
-
[x] Use the schema to make specific datatypes easier to display and change. For instance, if a key is marked as an enum with a fixed set of values, the panel would show a select box with enums as options (and, if the existing value isn't in the enum, it would still show it). We can have a few basic datatypes in the schema: boolean, enum, integer, float, text, with sensible options or regex to validate the value. The schema should probably be able to specify a sort order for "important" keys, which would appear before the default-sorted "unimportant" keys. Further, if a key is not set, the schema could specify if they key and empty value should be shown; if not, the user could still create a value for that key.
-
[ ] Extend the schema and UI to handle multiple users. For instance, if the "status" key is a multi-user key, then we really store
status-user-<user name>. For admins, we would show all user values (or perhaps have a toggle to show just their own OR all users' values)
Show and allow editing selected metadata (from the Girder item
metarecord) in a panel in the HistomicsTK interface.The current concept is that the metadata shown should be based on a schema that is stored in a specially named folder and item at the root of the Girder Collection or User. This schema would list the keys that can be set in the
metarecord along with an indication of what values that key can take (boolean, enum list, free text, and numerical range would be a good first pass). The schema should specify a human-display string to use as a label next to the control that allows setting the key (rather than using the key name) and display strings for entries in enum lists (to use as text in select boxes). If the metadata associated with the item does not contain the key, the controls should show an unset set rather than a default.If a user has permission to write to the Girder item, then they can change the values associated with the
metarecord. Some keys could be marked as read-only; these would not be editable even by a user with write permission.In the future, we may want to specify keys with some sort of per-user indicator. For instance, instead of
key: 'status'where there is one status per item for all users, we could have something likekey: 'status{user}'; internally we might store the data with a keystatus-user-<user name>. In this instance, the logged in user would only see their own value. In the Girder item page, all metadata values would still be visible.