<!-- 
RSS generated by JIRA (1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d) at Thu Feb 08 23:06:56 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary add field=key&field=summary to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>FOLIO Jira</title>
    <link>https://folio-org.atlassian.net</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>1001.0.0-SNAPSHOT</version>
        <build-number>100246</build-number>
        <build-date>07-02-2024</build-date>
    </build-info>

<item>
            <title>[FOLIO-592] meta-data section in FOLIO records (createdDate, updatedDate, creator, etc)</title>
                <link>https://folio-org.atlassian.net/browse/FOLIO-592</link>
                <project id="10290" key="FOLIO">FOLIO</project>
                    <description>&lt;p&gt;Consider returning this information in form of HTTP headers and include for any entity stored in FOLIO.&lt;/p&gt;</description>
                <environment></environment>
        <key id="80194">FOLIO-592</key>
            <summary>meta-data section in FOLIO records (createdDate, updatedDate, creator, etc)</summary>
                <type id="10003" iconUrl="https://folio-org.atlassian.net/rest/api/2/universal_avatar/view/type/issuetype/avatar/10318?size=medium">Task</type>
                                            <priority id="10000" iconUrl="https://dev.folio.org/assets/jira-priority/jira-p1.svg">P1</priority>
                        <status id="6" iconUrl="https://folio-org.atlassian.net/images/icons/statuses/closed.png" description="The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.">Closed</status>
                    <statusCategory id="3" key="done" colorName="green"/>
                                    <resolution id="10003">Done</resolution>
                                                        <assignee accountid="63e2a2771b13d42998e4e706">Marc Johnson</assignee>
                                                                <reporter accountid="557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d">Jakub Skoczen</reporter>
                                    <labels>
                            <label>core</label>
                            <label>for-next-sprint</label>
                            <label>sprint14</label>
                            <label>sprint16</label>
                            <label>sprint17</label>
                            <label>sprint19</label>
                            <label>team2</label>
                    </labels>
                <created>Mon, 8 May 2017 13:31:18 +0000</created>
                <updated>Fri, 18 Jan 2019 17:01:29 +0000</updated>
                            <resolved>Thu, 3 Aug 2017 14:22:00 +0000</resolved>
                                                                        <due></due>
                            <votes>0</votes>
                                    <watches>8</watches>
                                                    <timespent seconds="11700">3 hours, 15 minutes</timespent>
                                <comments>
                                                            <comment id="192034" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Tue, 23 May 2017 12:04:30 +0000"  >&lt;p&gt;looking at the normal workflow&lt;/p&gt;

&lt;p&gt;1. get request (rmb gets the requests , parses and calls implementing function)&lt;br/&gt;
2. process (implementing module gets called and handles request)&lt;br/&gt;
3. push to db (implementing module uses a db client - potentially rmb&apos;s client to save to db)&lt;br/&gt;
    3.a auto save timestamps&lt;br/&gt;
        Option 1: implementing module handles this, for example, the config module creates a trigger to create these two timestamps when it creates the schema during tenant activation&lt;br/&gt;
        Option 2: rmb  handles this, rmb adds two columns to module&apos;s tables - prefer not to do this&lt;/p&gt;

&lt;p&gt;3. get from db &lt;br/&gt;
    3.b auto get timestamp fields (rmb) - the rmb&apos;s postgres client can pull these two fields into the result set so that each result would be:  &lt;b&gt;id | json | creation date | update date&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;At this point the RMB hands off the result set to the implementing module and the module returns the result set which conforms to the declared raml - but there may be additional processing by the module  before it is returned.&lt;/p&gt;

&lt;p&gt;we can add two headers to the response so that the module will need to populate this info in the response, but it will need to be done by the module, the rmb is not db result set aware, only http response conforming to raml aware. however, how will this work for responses that include more then one record? it would seem cumbersome to have an array which matches up to the result set, no?&lt;/p&gt;</comment>
                                                            <comment id="192035" author="557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d" created="Tue, 23 May 2017 14:28:49 +0000"  >&lt;p&gt;Decided to allow users of RMB to wire headers (to be defined as a RAML trait) with database fields.&lt;/p&gt;

&lt;p&gt;Decision needs to be made about how to report timestamp field for lists of records (e.g user list)&lt;/p&gt;</comment>
                                                            <comment id="192036" author="557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d" created="Wed, 24 May 2017 11:57:47 +0000"  >&lt;p&gt;For the time being we have decided that the timestamp fields will be included directly in the schema, see 
    &lt;span class=&quot;jira-issue-macro resolved&quot; data-jira-key=&quot;MODUSERS-16&quot; &gt;
                &lt;a href=&quot;https://folio-org.atlassian.net/browse/MODUSERS-16&quot; class=&quot;jira-issue-macro-key issue-link&quot;  title=&quot;extend schema to support fields required by UIU-31&quot; &gt;
            &lt;img class=&quot;icon&quot; src=&quot;https://folio-org.atlassian.net/rest/api/2/universal_avatar/view/type/issuetype/avatar/10322?size=medium&quot; /&gt;
            MODUSERS-16
        &lt;/a&gt;
                                                    &lt;span class=&quot;aui-lozenge aui-lozenge-subtle aui-lozenge-success jira-macro-single-issue-export-pdf&quot;&gt;Closed&lt;/span&gt;
            &lt;/span&gt;
&lt;/p&gt;</comment>
                                                            <comment id="192037" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Thu, 25 May 2017 08:17:46 +0000"  >&lt;p&gt;one more minor issue to decide on, currently for example, in mod-config - the dates are part of the schema. there is an option to create a general schema which contains updateDate, creationDate and can be referenced to by a storage / bl schema. this can be a type of meta-data schema which contains those two field for now. a future field may be updatedBy, etc...&lt;/p&gt;</comment>
                                                            <comment id="192038" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Thu, 25 May 2017 11:49:23 +0000"  >&lt;p&gt;i can add the meta-data schema if we decide to go that route (to the raml repo)&lt;/p&gt;</comment>
                                                            <comment id="192039" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Sun, 28 May 2017 19:11:31 +0000"  >&lt;p&gt;i have done some research on this from the server side angle. if we decide on a metadata schema it can be populated by triggers in the following manner&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;

CREATE OR REPLACE FUNCTION update_user_trigger()
RETURNS TRIGGER AS $$
DECLARE
    inject jsonb;
BEGIN
    inject = json_build_object(&lt;span class=&quot;code-quote&quot;&gt;&apos;createDate&apos;&lt;/span&gt;,current_timestamp,&lt;span class=&quot;code-quote&quot;&gt;&apos;createdBy&apos;&lt;/span&gt;, current_user);
    NEW.jsonb = jsonb_set(NEW.jsonb, &lt;span class=&quot;code-quote&quot;&gt;&apos;{metaData}&apos;&lt;/span&gt; ,  inject , &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;);
    RETURN NEW;
END;
$$ language &lt;span class=&quot;code-quote&quot;&gt;&apos;plpgsql&apos;&lt;/span&gt;;
CREATE TRIGGER update_trigger BEFORE INSERT ON myuniversity3_mod_users.users FOR EACH ROW EXECUTE PROCEDURE  update_user_trigger();
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;the above will create a trigger on insert and create the metaData section, populating it with an createDate and and createdBy&lt;/p&gt;

&lt;p&gt;the same trigger (with a few minor tweaks) can also be added for on updates which will populate the metaData section with an updateDate and updatedBy fields. &lt;/p&gt;

&lt;p&gt;the above trigger has been tested however, i have not run intense performance testing on it.&lt;/p&gt;

&lt;p&gt;thoughts?&lt;/p&gt;</comment>
                                                            <comment id="192040" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Mon, 29 May 2017 07:10:12 +0000"  >&lt;p&gt;some performance numbers:&lt;/p&gt;

&lt;p&gt;4 cores / 8 threads (logical processors) (i7-6700hQ)&lt;br/&gt;
16 gb ram&lt;br/&gt;
ssd disk (dont have details)&lt;/p&gt;

&lt;p&gt;trigger performance is very linear (which is a good thing):&lt;/p&gt;

&lt;p&gt;Trigger update_trigger: time=8.678ms calls=1,000&lt;br/&gt;
Trigger update_trigger: time=80.979ms calls=10,000&lt;br/&gt;
Trigger - update_trigger: time=826.325ms calls=100,000&lt;br/&gt;
Trigger update_trigger: time=8659.108ms calls=1,000,000&lt;/p&gt;

&lt;p&gt;note this was tested using psql and seemed to be using just 1 cpu when running&lt;/p&gt;

&lt;p&gt;query used:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;

EXPLAIN ANALYSE INSERT INTO myuniversity3_mod_users.users(jsonb) SELECT &lt;span class=&quot;code-quote&quot;&gt;&apos;{&lt;span class=&quot;code-quote&quot;&gt;&quot;username&quot;&lt;/span&gt; : &lt;span class=&quot;code-quote&quot;&gt;&quot;shane14&quot;&lt;/span&gt;,&lt;span class=&quot;code-quote&quot;&gt;&quot;id&quot;&lt;/span&gt; : &lt;span class=&quot;code-quote&quot;&gt;&quot;b18e19f1-07b2-4367-9ee8-fa46a4881fd0&quot;&lt;/span&gt;, &lt;span class=&quot;code-quote&quot;&gt;&quot;active&quot;&lt;/span&gt; : &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;}&apos;&lt;/span&gt; FROM generate_series(1,100000);
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;note that the uuid was auto-generated by the db&lt;/p&gt;</comment>
                                                            <comment id="192041" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Tue, 30 May 2017 07:09:26 +0000"  >&lt;p&gt;so if there are no objections i would like to move forward with the metaData schema&lt;/p&gt;

&lt;p&gt;the schema at this point would look like this (to be placed in raml repo):&lt;br/&gt;
(note that module schemas will need to reference &apos;$ref&apos; this schema) &lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;
{
  &lt;span class=&quot;code-quote&quot;&gt;&quot;title&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;Metadata Schema&quot;&lt;/span&gt;,
  &lt;span class=&quot;code-quote&quot;&gt;&quot;type&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;object&quot;&lt;/span&gt;,
  &lt;span class=&quot;code-quote&quot;&gt;&quot;properties&quot;&lt;/span&gt;: {
    &lt;span class=&quot;code-quote&quot;&gt;&quot;createDate&quot;&lt;/span&gt;: {
      &lt;span class=&quot;code-quote&quot;&gt;&quot;type&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;string&quot;&lt;/span&gt;,
      &lt;span class=&quot;code-quote&quot;&gt;&quot;required&quot;&lt;/span&gt;: &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;
    },
    &lt;span class=&quot;code-quote&quot;&gt;&quot;updateDate&quot;&lt;/span&gt;: {
      &lt;span class=&quot;code-quote&quot;&gt;&quot;type&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;string&quot;&lt;/span&gt;,
      &lt;span class=&quot;code-quote&quot;&gt;&quot;required&quot;&lt;/span&gt;: &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;
    },
    &lt;span class=&quot;code-quote&quot;&gt;&quot;updatedBy&quot;&lt;/span&gt;: {
      &lt;span class=&quot;code-quote&quot;&gt;&quot;type&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;string&quot;&lt;/span&gt;
    },
    &lt;span class=&quot;code-quote&quot;&gt;&quot;createdBy&quot;&lt;/span&gt;: {
      &lt;span class=&quot;code-quote&quot;&gt;&quot;type&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;string&quot;&lt;/span&gt;
    }
  }
}
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;two triggers should be added to a storage module to auto populate a returned json response with this info - &lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;
CREATE OR REPLACE FUNCTION create_date_&amp;lt;TABLE&amp;gt;_trigger()
RETURNS TRIGGER AS $$
DECLARE
    inject jsonb;
BEGIN
    inject = json_build_object(&lt;span class=&quot;code-quote&quot;&gt;&apos;createDate&apos;&lt;/span&gt;,current_timestamp,&lt;span class=&quot;code-quote&quot;&gt;&apos;createdBy&apos;&lt;/span&gt;, current_user);
    NEW.jsonb = jsonb_set(NEW.jsonb, &lt;span class=&quot;code-quote&quot;&gt;&apos;{metaData}&apos;&lt;/span&gt; ,  inject , &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;);
    RETURN NEW;
END;
$$ language &lt;span class=&quot;code-quote&quot;&gt;&apos;plpgsql&apos;&lt;/span&gt;;
CREATE TRIGGER create_&amp;lt;TABLE&amp;gt;_trigger BEFORE INSERT ON myuniversity_mymodule.&amp;lt;TABLE&amp;gt; FOR EACH ROW EXECUTE PROCEDURE  create_date_&amp;lt;TABLE&amp;gt;_trigger();

CREATE OR REPLACE FUNCTION update_date_&amp;lt;TABLE&amp;gt;_trigger()
RETURNS TRIGGER AS $$
DECLARE
    inject jsonb;
BEGIN
    inject = json_build_object(&lt;span class=&quot;code-quote&quot;&gt;&apos;updateDate&apos;&lt;/span&gt;,current_timestamp,&lt;span class=&quot;code-quote&quot;&gt;&apos;updateBy&apos;&lt;/span&gt;, current_user);
    NEW.jsonb = jsonb_set(NEW.jsonb, &lt;span class=&quot;code-quote&quot;&gt;&apos;{metaData}&apos;&lt;/span&gt; ,  inject , &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;);
    RETURN NEW;
END;
$$ language &lt;span class=&quot;code-quote&quot;&gt;&apos;plpgsql&apos;&lt;/span&gt;;
CREATE TRIGGER update_&amp;lt;TABLE&amp;gt;_trigger BEFORE UPDATE ON myuniversity_mymodule.&amp;lt;TABLE&amp;gt; FOR EACH ROW EXECUTE PROCEDURE  update_date_&amp;lt;TABLE&amp;gt;_trigger();
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;there is one drawback to this:&lt;br/&gt;
while the update trigger fires with every update (hence , there will always be an updateDate entry in the response), the createDate is only populated when a record is created. if an updated is requested, and the metaData section isnt part of the json passed in, we will lose this info forever. this can be avoided by having the createDate as a separate column - the RMB postgres client pulls columns and can populate the fields in the returned json so that we dont lose this info.&lt;/p&gt;
</comment>
                                                            <comment id="192042" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Tue, 30 May 2017 07:26:33 +0000"  >&lt;p&gt;one last comment on this - if we agree on this approach &lt;/p&gt;

&lt;p&gt;raml files should add a reference to the metaData schema &lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;
- ../raml-util/schemas/metadata.schema: !include ../raml-util/schemas/metadata.schema
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;schema (for example userdata.json) should add a reference to the schema&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;
    &lt;span class=&quot;code-quote&quot;&gt;&quot;metaData&quot;&lt;/span&gt;: {
      &lt;span class=&quot;code-quote&quot;&gt;&quot;type&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;object&quot;&lt;/span&gt;,
      &lt;span class=&quot;code-quote&quot;&gt;&quot;$ref&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;../raml-util/schemas/metadata.schema&quot;&lt;/span&gt;
    }
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                                                            <comment id="192043" author="5bffed52a1b46046f530c8f7" created="Tue, 30 May 2017 10:04:17 +0000"  >&lt;p&gt;Sorry, I am late to this and lack the necessary background and context to comment intelligently; but of course I won&apos;t let that stop me.&lt;/p&gt;

&lt;p&gt;Is there a compelling reason to use &lt;tt&gt;string&lt;/tt&gt; for the datestamps instead of a proper &lt;tt&gt;datestamp&lt;/tt&gt; type?&lt;/p&gt;</comment>
                                                            <comment id="192044" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Tue, 30 May 2017 10:09:18 +0000"  >&lt;p&gt;since the server is generating this i was thinking about a &quot;type&quot; : &quot;string&quot; with a &quot;pattern&quot; field indicating the format. but date-time is legit&lt;/p&gt;</comment>
                                                            <comment id="192045" author="63e2a2771b13d42998e4e706" created="Tue, 30 May 2017 10:56:45 +0000"  >&lt;p&gt;Is it proposed that we include it within a domain representation, e.g:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;
{
  &lt;span class=&quot;code-quote&quot;&gt;&quot;username&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;jhandey&quot;&lt;/span&gt;,
  &lt;span class=&quot;code-quote&quot;&gt;&quot;id&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;7261ecaae3a74dc68b468e12a70b1aec&quot;&lt;/span&gt;,
  ...
  &lt;span class=&quot;code-quote&quot;&gt;&quot;personal&quot;&lt;/span&gt;: {
    &lt;span class=&quot;code-quote&quot;&gt;&quot;lastName&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;Handey&quot;&lt;/span&gt;,
    &lt;span class=&quot;code-quote&quot;&gt;&quot;firstName&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;Jack&quot;&lt;/span&gt;,
    ...
  },
  &lt;span class=&quot;code-quote&quot;&gt;&quot;metaData&quot;&lt;/span&gt;: {
    &lt;span class=&quot;code-quote&quot;&gt;&quot;createDate&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;2016-11-05T07:23:32Z&quot;&lt;/span&gt;
    ...
  },
}
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Given that createDate is a required property, are we are expecting a client to include this information in any request to create or update a record, or is the metadata object itself going to be optional and it is expected that a client won&apos;t provide any of this information in requests? This might be related to the question about keeping this information in the stored JSON, or separately (which I think is a challenging tradeoff).&lt;/p&gt;

&lt;p&gt;In the example schema above, the updateDate is required, does this mean that a newly created record, will have both a createDate and an updateDate?&lt;/p&gt;

&lt;p&gt;Personally, I&apos;d prefer that all of the properties were in the past tense, e.g. createdDate or updatedDate, but that might just be a stylistic viewpoint.&lt;/p&gt;</comment>
                                                            <comment id="192046" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Tue, 30 May 2017 11:21:50 +0000"  >&lt;p&gt;right, the metaData is optional, but this comes back to the issue of the client having to supply it when updating a record otherwise it is lost. i guess you could say that since the metaData is returned by the server as part of the object that it is part of the record and leaving it out means a type of update, but this is dangerous.&lt;/p&gt;

&lt;p&gt;i have no preference about past tense &lt;/p&gt;

&lt;p&gt;i would like to verify we are all on the same page from a metaData schema standpoint - the comments are good and the implementation can be tuned to accommodate.&lt;/p&gt;
</comment>
                                                            <comment id="192047" author="557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d" created="Tue, 30 May 2017 11:39:33 +0000"  >&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=63e2a2771b13d42998e4e706&quot; class=&quot;user-hover&quot; rel=&quot;63e2a2771b13d42998e4e706&quot; data-account-id=&quot;63e2a2771b13d42998e4e706&quot; accountid=&quot;63e2a2771b13d42998e4e706&quot; rel=&quot;noreferrer&quot;&gt;Marc Johnson&lt;/a&gt; &lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=712020%3A32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; class=&quot;user-hover&quot; rel=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; data-account-id=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; accountid=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; rel=&quot;noreferrer&quot;&gt;shale99&lt;/a&gt; I agree with Marc&apos;s stylistic viewpoint, let&apos;s go for createdDate and updatedDate. &lt;/p&gt;

&lt;p&gt;What is the standard way for dealing with non-optional but server-provided fields, like the metadata section? Is there a recommendation in JSON schema or JSON-api?&lt;/p&gt;</comment>
                                                            <comment id="192048" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Tue, 30 May 2017 11:42:52 +0000"  >&lt;p&gt;i will check&lt;/p&gt;</comment>
                                                            <comment id="192049" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Thu, 1 Jun 2017 09:29:16 +0000"  >&lt;p&gt;for the schema type part&lt;/p&gt;

&lt;p&gt;this can either be &lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;
type: date-time
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;


&lt;p&gt;or&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;

type: string
pattern: &lt;span class=&quot;code-quote&quot;&gt;&quot;^[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}\\.[0-9]{6}\\+[0-9]{2}:[0-9]{2}$&quot;&lt;/span&gt;
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;


&lt;p&gt;can not combine type: date-time with pattern - i think the pattern is a bit clearer for someone looking at the schema - we can add a description as well with more info.&lt;/p&gt;

&lt;p&gt;on the other hand - we can add a description to the date-time type with the pattern.&lt;/p&gt;

&lt;p&gt;validating tools will have an easier time with the type string and its pattern - so this would be my vote. if anyone feels otherwise please let me know &lt;/p&gt;</comment>
                                                            <comment id="192050" author="63e2a2771b13d42998e4e706" created="Thu, 1 Jun 2017 09:49:46 +0000"  >&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=712020%3A32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; class=&quot;user-hover&quot; rel=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; data-account-id=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; accountid=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; rel=&quot;noreferrer&quot;&gt;shale99&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;If I&apos;m understanding the pattern option, we would effectively be defining our own profile of ISO8601 that defines a date and time without timezone information, is that a sensible interpretation? Would this be interpreted by the RAML-Module-Builder as a date time in the POJOs or kept as a string?&lt;/p&gt;

&lt;p&gt;My personal preference is to use the date-time type as it is defined as part of the JSON.Schema validation specification (I find &lt;a href=&quot;https://tools.ietf.org/html/rfc3339#section-5.6&quot; class=&quot;external-link&quot; rel=&quot;nofollow noreferrer&quot;&gt;https://tools.ietf.org/html/rfc3339#section-5.6&lt;/a&gt; easier to read than a regular expression, but I might be alone in that regard). I was under the impression that the RAML-module-builder had recently been updated to support this?&lt;/p&gt;</comment>
                                                            <comment id="192051" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Thu, 1 Jun 2017 10:04:18 +0000"  >&lt;p&gt;not really&lt;/p&gt;

&lt;p&gt;ISO 8601 Combined date and time in UTC looks like this: 2017-06-01T09:33:49+00:00&lt;br/&gt;
(this is represented by the regex above)&lt;br/&gt;
this is the format rmb saves / retrieves to the db when encountering date-time types in schema&lt;br/&gt;
this is not necessarily the format that will be used by non rmb modules when encountering a date-time type&lt;/p&gt;</comment>
                                                            <comment id="192052" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Thu, 1 Jun 2017 10:12:11 +0000"  >&lt;p&gt;my mistake - yes, this is iso with microsecond resolution.&lt;br/&gt;
i guess we can change the 6 digit partial second resolution to a two digit partial second resolution. right now rmb uses 6 digits&lt;/p&gt;</comment>
                                                            <comment id="192053" author="63e2a2771b13d42998e4e706" created="Thu, 1 Jun 2017 10:42:09 +0000"  >&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=712020%3A32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; class=&quot;user-hover&quot; rel=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; data-account-id=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; accountid=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; rel=&quot;noreferrer&quot;&gt;shale99&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I think I&apos;m confused, so I&apos;ll share my reflection and hopefully you can help me with my understanding by correcting my understanding.&lt;/p&gt;

&lt;p&gt;We are attempting to define a standard for date time representation in FOLIO APIs (maybe this conversation needs to move to &lt;span class=&quot;error&quot;&gt;&amp;#91;DMOD-256&amp;#93;&lt;/span&gt;).&lt;/p&gt;

&lt;p&gt;&lt;b&gt;Interface&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;There are two proposed options for API representations:&lt;/p&gt;

&lt;p&gt;1. String type with pattern (see above), that is an ISO8601 profile (subset of available representations) and represents date and time (up to partial second), with no time zone information (assumed to be UTC).&lt;/p&gt;

&lt;p&gt;2. date-time type (defined in the JSON.schema validation specification) and is also an ISO8601 profile (from RFC3339) which  represents date and time (up to partial second) with explicit time zone information.&lt;/p&gt;

&lt;p&gt;&lt;b&gt;Standard Implementation&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;The RAML-module-builder currently converts a property of type date-time into a Java DateTime in the POJO and stores this information in the format described above (date and time, with optional partial seconds and no time zone information). I don&apos;t know what the RAML-module-builder would do in the pattern case, I assume it will keep the string as is.&lt;/p&gt;</comment>
                                                            <comment id="192055" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Thu, 1 Jun 2017 11:00:07 +0000"  >&lt;p&gt;will explain my thinking...&lt;/p&gt;

&lt;p&gt;lets start with the meta data schema for starters&lt;br/&gt;
we are talking about a generic schema available in the raml repo to all developers. so we need to indicate the format of the update and created date fields.&lt;/p&gt;

&lt;p&gt;option 1 indicate that these fields are of type date-type &lt;br/&gt;
this is a legit option, the rmb handles this as well and formats the content of the field into a date and time value format indicated previously. meaning all rmb storage modules will save the jsons in the database in a single format as indicated .&lt;/p&gt;

&lt;p&gt;the one issue i have with this would be non-rmb modules / api consumers - there is no info in the schema indicating what they should expect for a date-time type. this is solvable by documentation and adding a description field to the date entries, however, an api consumer using a third party json validator will have a bit more work to do to indicate what an acceptable date-time value is acceptable.&lt;br/&gt;
for example, postgres jsonb columns support indicating validation at the db level for an inserted json - so that if the json does not validate , it wont be inserted - other 3rd party products may offer the same tooling - the question is, if we pass in a type: date-time - will all those validation tools validate the value in the same way. passing a string with a pattern will mean yes. this is the only thing that bothers me a bit with the type: date-time&lt;/p&gt;


</comment>
                                                            <comment id="192057" author="5bffed52a1b46046f530c8f7" created="Thu, 1 Jun 2017 11:16:42 +0000"  >&lt;p&gt;I can&apos;t see any significant reason not to use a real date-time type. It seems we already have all the support we need within our own projects; and support for it is only going to improve in other people&apos;s tools. Let&apos;s say what we mean.&lt;/p&gt;</comment>
                                                            <comment id="192058" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Thu, 1 Jun 2017 11:21:32 +0000"  >&lt;p&gt;that is kind of the issue i think - with date-time , we arent really saying what we mean, we are saying in general this is a date-time field, but we give no info to parsers, validators what that date-time field really means from a content standpoint.&lt;/p&gt;

&lt;p&gt;I am ok going with the date-time field as well, my main concern was what i stated, it isnt a burning issue with me to go with the strings&lt;/p&gt;</comment>
                                                            <comment id="192059" author="5bffed52a1b46046f530c8f7" created="Thu, 1 Jun 2017 12:18:18 +0000"  >&lt;p&gt;Hmm. Well, saying the field&apos;s type is dateTime is certainly more honest and explicit than saying string.&lt;/p&gt;

&lt;p&gt;Your concern is that tooling support may not take advantage of what can be known about the dataTime field. But the key tool in our project is RMB, and that does support it. Which to my mind is good enough.&lt;/p&gt;

&lt;p&gt;But I am well out of the mainstream of this issue, so if you guys who are better informed and closer to the metal have differing opinions I am more than happy to stand down.&lt;/p&gt;</comment>
                                                            <comment id="192060" author="63e2a2771b13d42998e4e706" created="Thu, 1 Jun 2017 13:06:41 +0000"  >&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=712020%3A32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; class=&quot;user-hover&quot; rel=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; data-account-id=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; accountid=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; rel=&quot;noreferrer&quot;&gt;shale99&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I agree that both module authors and clients need a clear understanding of expectations. From my perspective, the &lt;a href=&quot;http://json-schema.org/latest/json-schema-validation.html#rfc.section.8.3.1&quot; class=&quot;external-link&quot; rel=&quot;nofollow noreferrer&quot;&gt;validation standard&lt;/a&gt; states what it is intended and is supported by fairly comprehensive documentation in &lt;a href=&quot;https://tools.ietf.org/html/rfc3339#section-5.6&quot; class=&quot;external-link&quot; rel=&quot;nofollow noreferrer&quot;&gt;RFC3339&lt;/a&gt;. Would referring directly to that allay some of your concerns around clarity?&lt;/p&gt;

&lt;p&gt;As far as implementation goes, I don&apos;t know what the tool support for JSON schema validation or RFC3339 is like. I would expect that many people would just use ISO8601 validation, and so be slightly weaker than the specification, which could be a concern for compatibility (we could support that with a regular expression for internal use).&lt;/p&gt;
</comment>
                                                            <comment id="192061" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Mon, 5 Jun 2017 08:10:49 +0000"  >&lt;p&gt;i would like to summarize the current status&lt;/p&gt;

&lt;p&gt;1. a metadata schema will be created and placed in the raml repo&lt;br/&gt;
    a. the metadata schema will contain two fields at this point&lt;br/&gt;
        i. updatedDate , createdDate&lt;br/&gt;
    b. storage / bl schemas should reference this schema&lt;br/&gt;
2. storage modules will need to create two triggers for each table (table representing a json)&lt;br/&gt;
    a. trigger on insert - this will be slightly different then the trigger indicated  previously - this trigger will populate a createdDate column in the table. The rmb will auto populate the metadata schema with this value when returning results from this table&lt;br/&gt;
    b. trigger on update - can either work as the insert trigger, or as  previously described (inject metadata into object in db) - i prefer as insert trigger&lt;br/&gt;
   NOTE that rmb already does this type of inject already - this will hence not be a big change in the rmb.&lt;br/&gt;
3. date format - seems like the consensus is to go with date-time type. note that this will leave the actual format in the hands of the developer / consumer - there are 2 variants (with Z / without Z + indicating offset of UTC) - so there may be two representations of date&lt;br/&gt;
4. the metadata schema should be declared optional - the client does not need to pass it in. it will, however, always be returned by the server&lt;br/&gt;
    a. the createdDate - required&lt;br/&gt;
    b. the updatedDate - optional (relevant only if record was updated)&lt;/p&gt;

&lt;p&gt;i would like to finalize this and push into a release - so please comment if you find something you do not necessarily agree with&lt;/p&gt;</comment>
                                                            <comment id="192062" author="5bffed5e2434bf3a1a91d37a" created="Mon, 5 Jun 2017 10:00:22 +0000"  >&lt;blockquote&gt;&lt;p&gt;i would like to summarize the current status&lt;br/&gt;
1. a metadata schema will be created and placed in the raml repo&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;     To make it reusable I assume, good&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;a. the metadata schema will contain two fields at this point&lt;br/&gt;
i. updatedDate , createdDate&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;     Okay, good&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;b. storage / bl schemas should reference this schema&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;     That&apos;s the reuse bit?&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;2. storage modules will need to create two triggers for each table (table representing a json)&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;    Out of curiosity (as I&apos;m only going through the RMB documentation now for the first time in quite a while): Is the module developer doing this by Java annotations somehow or by explicit  DDL in postgres?&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;a. trigger on insert - this will be slightly different then the trigger indicated previously - this trigger will populate a createdDate column in the table. The rmb will auto populate the metadata schema with this value when returning results from this table&lt;br/&gt;
b. trigger on update - can either work as the insert trigger, or as previously described (inject metadata into object in db) - i prefer as insert trigger&lt;br/&gt;
NOTE that rmb already does this type of inject already - this will hence not be a big change in the rmb.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;   Guess I don&apos;t get why the trigger on update is not an update trigger but I&apos;m sure there&apos;s a good explanation for that.&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;3. date format - seems like the consensus is to go with date-time type. note that this will leave the actual format in the hands of the developer / consumer - there are 2 variants (with Z / without Z + indicating offset of UTC) - so there may be two representations of date&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;  Right, the JavaScript client code seems to seamlessly parse either flavor of ISO8601, but maybe the client would need to know what specific variation of ISO8601 that is behind &quot;date-time&quot; when pushing data to the module? I think &lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=63e2a2771b13d42998e4e706&quot; class=&quot;user-hover&quot; rel=&quot;63e2a2771b13d42998e4e706&quot; data-account-id=&quot;63e2a2771b13d42998e4e706&quot; accountid=&quot;63e2a2771b13d42998e4e706&quot; rel=&quot;noreferrer&quot;&gt;Marc Johnson&lt;/a&gt; suggested that we documented the specific format somehow, I guess that would be good, especially if it is so that it breaks an interface if the internal, specific representation of date-time were to be changed in a module (between using Z and not for instance) ?&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;4. the metadata schema should be declared optional - the client does not need to pass it in. it will, however, always be returned by the server&lt;br/&gt;
a. the createdDate - required&lt;br/&gt;
b. the updatedDate - optional (relevant only if record was updated)&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;Sounds good.&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;i would like to finalize this and push into a release - so please comment if you find something you do not necessarily agree with&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;It looks fine to me (with my only question mark being whether variations in internal date-time representations can break an interface without it showing in the API spec) &lt;/p&gt;</comment>
                                                            <comment id="192063" author="63e2a2771b13d42998e4e706" created="Mon, 5 Jun 2017 10:33:01 +0000"  >&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=712020%3A32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; class=&quot;user-hover&quot; rel=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; data-account-id=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; accountid=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; rel=&quot;noreferrer&quot;&gt;shale99&lt;/a&gt; &lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=5bffed5e2434bf3a1a91d37a&quot; class=&quot;user-hover&quot; rel=&quot;5bffed5e2434bf3a1a91d37a&quot; data-account-id=&quot;5bffed5e2434bf3a1a91d37a&quot; accountid=&quot;5bffed5e2434bf3a1a91d37a&quot; rel=&quot;noreferrer&quot;&gt;Niels Erik Nielsen&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I&apos;m mostly interested in the behaviour from the clients perspective (though the answers might affect the discussion about how to store the information), so I&apos;ll focus on points 3 and 4. If my interpretation is reasonable, I have a couple of questions.&lt;/p&gt;

&lt;blockquote&gt;&lt;p&gt;3. date format - seems like the consensus is to go with date-time type. note that this will leave the actual format in the hands of the developer / consumer - there are 2 variants (with Z / without Z + indicating offset of UTC) - so there may be two representations of date&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;Do we want to be strict about only having audit metadata dates be represented explicitly in UTC?&lt;/p&gt;

&lt;p&gt;If we do, then the date-time format isn&apos;t necessarily strict enough for our purposes and we might want to create a very specific profile of 8601 which only allows Z and not a specified offset.&lt;/p&gt;

&lt;blockquote&gt;&lt;p&gt;4. the metadata schema should be declared optional - the client does not need to pass it in. it will, however, always be returned by the server&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;and &lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=5bffed5e2434bf3a1a91d37a&quot; class=&quot;user-hover&quot; rel=&quot;5bffed5e2434bf3a1a91d37a&quot; data-account-id=&quot;5bffed5e2434bf3a1a91d37a&quot; accountid=&quot;5bffed5e2434bf3a1a91d37a&quot; rel=&quot;noreferrer&quot;&gt;Niels Erik Nielsen&lt;/a&gt; related comment:&lt;/p&gt;

&lt;blockquote&gt;&lt;p&gt;Right, the JavaScript client code seems to seamlessly parse either flavor of ISO8601, but maybe the client would need to know what specific variation of ISO8601 that is behind &quot;date-time&quot; when pushing data to the module?&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;My interpretation of the conversation so far has been that the server owns this information, is this a sensible interpretation?&lt;/p&gt;

&lt;p&gt;If so, what should the behaviour be for clients supplying audit metadata? For example, what should the server do if the client provides a different createdDate? Or if it repeats back the current audit metadata?&lt;/p&gt;

&lt;p&gt;If the expectation is that the client should omit this information in subsequent requests, then it does not need to understand which format to create only how to read the acceptable formats (which it appears to be able to do already).&lt;/p&gt;</comment>
                                                            <comment id="192064" author="5bffed52a1b46046f530c8f7" created="Mon, 5 Jun 2017 10:49:38 +0000"  >&lt;p&gt;Sorry to bring this up so late in the day, but ...&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;a. the metadata schema will contain two fields at this point&lt;br/&gt;
i. updatedDate , createdDate&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;What would it take to also include &lt;tt&gt;updatedBy&lt;/tt&gt; and &lt;tt&gt;createdBy&lt;/tt&gt; fields, that tell us &lt;em&gt;who&lt;/em&gt; created and most recently updated the record? I think those would also be useful. Perhaps that belongs in a separate Jira, but I guess it&apos;s at least potentially relevant to this conversation.&lt;/p&gt;

&lt;p&gt;Also: I agree with Marc in being perplexed about what it would be mean for a client to try to set these automatic fields. I would support that a request doing this be rejected with a 4xx error.&lt;/p&gt;</comment>
                                                            <comment id="192065" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Mon, 5 Jun 2017 10:56:54 +0000"  >&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=63e2a2771b13d42998e4e706&quot; class=&quot;user-hover&quot; rel=&quot;63e2a2771b13d42998e4e706&quot; data-account-id=&quot;63e2a2771b13d42998e4e706&quot; accountid=&quot;63e2a2771b13d42998e4e706&quot; rel=&quot;noreferrer&quot;&gt;Marc Johnson&lt;/a&gt; -&lt;/p&gt;

&lt;blockquote&gt;&lt;p&gt;Do we want to be strict about only having audit metadata dates be represented explicitly in UTC?&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;i thought you were saying the exact opposite, no? i have stated that previously, hence wanted this as a specific pattern + string since this removes any ambiguity, but you and mike have argued against  that and that date-time as spec&apos;ed by json schema is sufficient. or am i missing your point here?&lt;/p&gt;

&lt;p&gt;since the server is always populating these fields, it does not matter what the client provides , as it will always be overwritten , hence ignored. i think that can be documented, i dont know if i would fail a legit request because of that&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=5bffed52a1b46046f530c8f7&quot; class=&quot;user-hover&quot; rel=&quot;5bffed52a1b46046f530c8f7&quot; data-account-id=&quot;5bffed52a1b46046f530c8f7&quot; accountid=&quot;5bffed52a1b46046f530c8f7&quot; rel=&quot;noreferrer&quot;&gt;Mike Taylor&lt;/a&gt; - if you look at one of my previous comments about this issue - you will see that i indicated that a createdBy and an updatedBy can be included as well. since we dont necessarily need them now i am ok with adding them now or later.&lt;/p&gt;

&lt;p&gt;original suggestion :&lt;/p&gt;


&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;
{
  &lt;span class=&quot;code-quote&quot;&gt;&quot;title&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;Metadata Schema&quot;&lt;/span&gt;,
  &lt;span class=&quot;code-quote&quot;&gt;&quot;type&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;object&quot;&lt;/span&gt;,
  &lt;span class=&quot;code-quote&quot;&gt;&quot;properties&quot;&lt;/span&gt;: {
    &lt;span class=&quot;code-quote&quot;&gt;&quot;createDate&quot;&lt;/span&gt;: {
      &lt;span class=&quot;code-quote&quot;&gt;&quot;type&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;string&quot;&lt;/span&gt;,
      &lt;span class=&quot;code-quote&quot;&gt;&quot;required&quot;&lt;/span&gt;: &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;
    },
    &lt;span class=&quot;code-quote&quot;&gt;&quot;updateDate&quot;&lt;/span&gt;: {
      &lt;span class=&quot;code-quote&quot;&gt;&quot;type&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;string&quot;&lt;/span&gt;,
      &lt;span class=&quot;code-quote&quot;&gt;&quot;required&quot;&lt;/span&gt;: &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;
    },
    &lt;span class=&quot;code-quote&quot;&gt;&quot;updatedBy&quot;&lt;/span&gt;: {
      &lt;span class=&quot;code-quote&quot;&gt;&quot;type&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;string&quot;&lt;/span&gt;
    },
    &lt;span class=&quot;code-quote&quot;&gt;&quot;createdBy&quot;&lt;/span&gt;: {
      &lt;span class=&quot;code-quote&quot;&gt;&quot;type&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;string&quot;&lt;/span&gt;
    }
  }
}
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                                                            <comment id="192066" author="5bffed52a1b46046f530c8f7" created="Mon, 5 Jun 2017 10:58:25 +0000"  >&lt;p&gt;Cool, thanks. Sorry that I missed that &amp;#8211; this thread has got long &lt;img class=&quot;emoticon&quot; src=&quot;/images/icons/emoticons/smile.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                                                            <comment id="192067" author="63e2a2771b13d42998e4e706" created="Mon, 5 Jun 2017 11:25:37 +0000"  >&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=712020%3A32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; class=&quot;user-hover&quot; rel=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; data-account-id=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; accountid=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; rel=&quot;noreferrer&quot;&gt;shale99&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I may have mixed up this context with the general context of &lt;span class=&quot;error&quot;&gt;&amp;#91;DMOD-256&amp;#93;&lt;/span&gt;, which might explain my prior confusion (I had interpreted the suggestion as being used for the general case, which is far more important to me).&lt;/p&gt;

&lt;p&gt;I agree that whatever policy we choose about client provided metadata then it should be clearly documented, be that either refusal or that it will be entirely ignored (in cases like this, the intended semantics of PUT get pretty complicated).&lt;/p&gt;

&lt;p&gt;If we definitely want to restrict the audit metadata date time information to only be UTC, then we might be better in providing a specific pattern stating that explicitly.&lt;/p&gt;

&lt;p&gt;If the policy will be that the client provided information will be ignored, then I think the practical difference between a custom pattern and the predefined pattern is fairly limited.&lt;/p&gt;</comment>
                                                            <comment id="192068" author="5bffed5e2434bf3a1a91d37a" created="Mon, 5 Jun 2017 11:34:02 +0000"  >&lt;p&gt;Right, &lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=63e2a2771b13d42998e4e706&quot; class=&quot;user-hover&quot; rel=&quot;63e2a2771b13d42998e4e706&quot; data-account-id=&quot;63e2a2771b13d42998e4e706&quot; accountid=&quot;63e2a2771b13d42998e4e706&quot; rel=&quot;noreferrer&quot;&gt;Marc Johnson&lt;/a&gt;, my bad, in the scenario discussed here it doesn&apos;t matter to the client what flavor of ISO8601 is used. My thoughts were straddling into the issue of the format of date-time dates that the client &lt;em&gt;does&lt;/em&gt; control. &lt;/p&gt;

&lt;p&gt;Well, DMOD-256 like you just said &lt;img class=&quot;emoticon&quot; src=&quot;/images/icons/emoticons/smile.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt; &lt;/p&gt;</comment>
                                                            <comment id="192069" author="557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d" created="Tue, 20 Jun 2017 14:14:55 +0000"  >&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=712020%3A32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; class=&quot;user-hover&quot; rel=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; data-account-id=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; accountid=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; rel=&quot;noreferrer&quot;&gt;shale99&lt;/a&gt; &lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=5c38e8d616ac1e4f7cbc660a&quot; class=&quot;user-hover&quot; rel=&quot;5c38e8d616ac1e4f7cbc660a&quot; data-account-id=&quot;5c38e8d616ac1e4f7cbc660a&quot; accountid=&quot;5c38e8d616ac1e4f7cbc660a&quot; rel=&quot;noreferrer&quot;&gt;Kurt Nordstrom&lt;/a&gt; we didn&apos;t manage to discuss this on the call: what is the current status of this work?&lt;/p&gt;

&lt;p&gt;I&apos;d like to make sure we can wrap up 
    &lt;span class=&quot;jira-issue-macro resolved&quot; data-jira-key=&quot;UIU-31&quot; &gt;
                &lt;a href=&quot;https://folio-org.atlassian.net/browse/UIU-31&quot; class=&quot;jira-issue-macro-key issue-link&quot;  title=&quot;Add Date Stamps to User Record&quot; &gt;
            &lt;img class=&quot;icon&quot; src=&quot;https://folio-org.atlassian.net/rest/api/2/universal_avatar/view/type/issuetype/avatar/10309?size=medium&quot; /&gt;
            UIU-31
        &lt;/a&gt;
                                                    &lt;span class=&quot;aui-lozenge aui-lozenge-subtle aui-lozenge-success jira-macro-single-issue-export-pdf&quot;&gt;Closed&lt;/span&gt;
            &lt;/span&gt;
 quickly, if the easier way forward is to set those fields in mod-user rather than in the DB through a trigger &amp;#8211; let&apos;s go for that. &lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=712020%3A32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; class=&quot;user-hover&quot; rel=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; data-account-id=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; accountid=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; rel=&quot;noreferrer&quot;&gt;shale99&lt;/a&gt; you mentioned that you produced a meta-data schema that include the timestamp fields? How does it look like and how is it used?&lt;/p&gt;</comment>
                                                            <comment id="192070" author="5c38e8d616ac1e4f7cbc660a" created="Tue, 20 Jun 2017 15:20:12 +0000"  >&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3Ab8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; class=&quot;user-hover&quot; rel=&quot;557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; data-account-id=&quot;557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; accountid=&quot;557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; rel=&quot;noreferrer&quot;&gt;Jakub Skoczen&lt;/a&gt; I can go ahead and add a routine to mod-users to update the fields whenever there&apos;s a write. That will get us to done for now, and perhaps we can settle on a system wide convention for the next sprint?&lt;/p&gt;</comment>
                                                            <comment id="192071" author="557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d" created="Wed, 26 Jul 2017 07:56:48 +0000"  >&lt;p&gt;We have decided that it&apos;s better to return the timestamps as part of the user. &lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=712020%3A32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; class=&quot;user-hover&quot; rel=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; data-account-id=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; accountid=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; rel=&quot;noreferrer&quot;&gt;shale99&lt;/a&gt; remaining question is if we can standardize this somehow across schemas, is there an equivalent concept to RAML &apos;traits&apos; in JSON schemas?&lt;/p&gt;</comment>
                                                            <comment id="192072" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Wed, 26 Jul 2017 08:00:45 +0000"  >&lt;p&gt;create a metaData schema to hold info about the object - two fields may be update and creation date, additional info may be added in the future (updatedBy, etc...) - and then reference the metaData schema from all schemas.&lt;br/&gt;
note that the current creation date impl is problematic and should not be considered reliable - there is a mechanism in place to do this via a trigger in the db so that this value is not tampered with / lost - during updates&lt;/p&gt;</comment>
                                                            <comment id="192073" author="63e2a2771b13d42998e4e706" created="Thu, 27 Jul 2017 11:34:45 +0000"  >&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=712020%3A32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; class=&quot;user-hover&quot; rel=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; data-account-id=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; accountid=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; rel=&quot;noreferrer&quot;&gt;shale99&lt;/a&gt; &lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3Ab8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; class=&quot;user-hover&quot; rel=&quot;557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; data-account-id=&quot;557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; accountid=&quot;557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; rel=&quot;noreferrer&quot;&gt;Jakub Skoczen&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Does this mean that this information would look something like (in the case of a user):&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;
{
	&lt;span class=&quot;code-quote&quot;&gt;&quot;id&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;9ed6bc8e-c833-4788-baa7-024611f931a3&quot;&lt;/span&gt;,
        ...
	&lt;span class=&quot;code-quote&quot;&gt;&quot;audit&quot;&lt;/span&gt;: {
		&lt;span class=&quot;code-quote&quot;&gt;&quot;createdUser&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;9b2d46ee-707c-4a12-998f-d65ed9baa0e5&quot;&lt;/span&gt;,
		&lt;span class=&quot;code-quote&quot;&gt;&quot;createdDate&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;2017-07-25T22:06:54Z&quot;&lt;/span&gt;,
		&lt;span class=&quot;code-quote&quot;&gt;&quot;updatedUser&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;07f4e0fe-2f31-46f1-8018-16a14dd2bc3d&quot;&lt;/span&gt;,
		&lt;span class=&quot;code-quote&quot;&gt;&quot;updatedDate&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;2017-07-27T11:04:22Z&quot;&lt;/span&gt;
	}
}
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;I don&apos;t think I have seen an example of this yet, if there is one please refer me to that instead.&lt;/p&gt;

&lt;p&gt;(This doesn&apos;t yet take into account the conversations about operator and name of the property we should use, in various issues like 
    &lt;span class=&quot;jira-issue-macro resolved&quot; data-jira-key=&quot;UIREQ-1&quot; &gt;
                &lt;a href=&quot;https://folio-org.atlassian.net/browse/UIREQ-1&quot; class=&quot;jira-issue-macro-key issue-link&quot;  title=&quot;Requests: View Request Details v1&quot; &gt;
            &lt;img class=&quot;icon&quot; src=&quot;https://folio-org.atlassian.net/rest/api/2/universal_avatar/view/type/issuetype/avatar/10309?size=medium&quot; /&gt;
            UIREQ-1
        &lt;/a&gt;
                                                    &lt;span class=&quot;aui-lozenge aui-lozenge-subtle aui-lozenge-success jira-macro-single-issue-export-pdf&quot;&gt;Closed&lt;/span&gt;
            &lt;/span&gt;
 and 
    &lt;span class=&quot;jira-issue-macro resolved&quot; data-jira-key=&quot;CIRCSTORE-16&quot; &gt;
                &lt;a href=&quot;https://folio-org.atlassian.net/browse/CIRCSTORE-16&quot; class=&quot;jira-issue-macro-key issue-link&quot;  title=&quot;operator_id is missing in loan_history_table&quot; &gt;
            &lt;img class=&quot;icon&quot; src=&quot;https://folio-org.atlassian.net/rest/api/2/universal_avatar/view/type/issuetype/avatar/10322?size=medium&quot; /&gt;
            CIRCSTORE-16
        &lt;/a&gt;
                                                    &lt;span class=&quot;aui-lozenge aui-lozenge-subtle aui-lozenge-success jira-macro-single-issue-export-pdf&quot;&gt;Closed&lt;/span&gt;
            &lt;/span&gt;
)&lt;/p&gt;</comment>
                                                            <comment id="192074" author="557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d" created="Thu, 27 Jul 2017 11:38:21 +0000"  >&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=63e2a2771b13d42998e4e706&quot; class=&quot;user-hover&quot; rel=&quot;63e2a2771b13d42998e4e706&quot; data-account-id=&quot;63e2a2771b13d42998e4e706&quot; accountid=&quot;63e2a2771b13d42998e4e706&quot; rel=&quot;noreferrer&quot;&gt;Marc Johnson&lt;/a&gt; I think this makes sense, maybe we should use a more generic term than &quot;audit&quot;? Anyhow this looks good, what do you think &lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=712020%3A32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; class=&quot;user-hover&quot; rel=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; data-account-id=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; accountid=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; rel=&quot;noreferrer&quot;&gt;shale99&lt;/a&gt;?&lt;/p&gt;</comment>
                                                            <comment id="192075" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Thu, 27 Jul 2017 11:39:57 +0000"  >&lt;p&gt;this doesnt exist - you can scroll up this convo (to 30/May/17 ) to see the metadata schema i suggested along with date formatting. i would prefer not to call this audit but rather metadata on the actual record &lt;/p&gt;</comment>
                                                            <comment id="192076" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Thu, 27 Jul 2017 11:44:05 +0000"  >&lt;p&gt;also, i would prefer to use a username and not uuid - in folio, a username is unique and can be used to lookup anything about a user (including the uuid if needed) - on the bonus side - it can be displayed in the ui without a need for additional http requests as displaying a uuid as an operator wont mean anything to the end user  without an additional lookup&lt;/p&gt;</comment>
                                                            <comment id="192077" author="63e2a2771b13d42998e4e706" created="Thu, 27 Jul 2017 11:48:56 +0000"  >&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=712020%3A32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; class=&quot;user-hover&quot; rel=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; data-account-id=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; accountid=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; rel=&quot;noreferrer&quot;&gt;shale99&lt;/a&gt; &lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3Ab8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; class=&quot;user-hover&quot; rel=&quot;557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; data-account-id=&quot;557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; accountid=&quot;557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; rel=&quot;noreferrer&quot;&gt;Jakub Skoczen&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Apologies, I&apos;d forgotten we&apos;d had many of these conversations already.&lt;/p&gt;

&lt;p&gt;I&apos;m not attached to the audit name, my primary interest in the property name is that it effectively becomes reserved in all/most of our schema, so I think we need to be really careful when choosing it (e.g. creator, which was suggested elsewhere, I think could easily clash with bibliographic metadata).&lt;/p&gt;

&lt;p&gt;If I&apos;m understanding this in the context of other conversations we&apos;ve been having, the idea of operator (for loans / requests) is actually the updatedBy (I prefer updatedUser as it makes it explicit it is a reference to a user record) and we don&apos;t need to define that as well?&lt;/p&gt;</comment>
                                                            <comment id="192078" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Thu, 27 Jul 2017 11:54:40 +0000"  >&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=63e2a2771b13d42998e4e706&quot; class=&quot;user-hover&quot; rel=&quot;63e2a2771b13d42998e4e706&quot; data-account-id=&quot;63e2a2771b13d42998e4e706&quot; accountid=&quot;63e2a2771b13d42998e4e706&quot; rel=&quot;noreferrer&quot;&gt;Marc Johnson&lt;/a&gt; - not sure i follow the need to define comment ? (maybe updatedByUser)? the updatedBy sounds very understandable &lt;img class=&quot;emoticon&quot; src=&quot;/images/icons/emoticons/smile.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;br/&gt;
but i am the last person to comment on english &lt;/p&gt;</comment>
                                                            <comment id="192079" author="63e2a2771b13d42998e4e706" created="Thu, 27 Jul 2017 11:59:21 +0000"  >&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=712020%3A32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; class=&quot;user-hover&quot; rel=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; data-account-id=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; accountid=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; rel=&quot;noreferrer&quot;&gt;shale99&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I think I saw a similar question to this on 
    &lt;span class=&quot;jira-issue-macro resolved&quot; data-jira-key=&quot;CIRCSTORE-16&quot; &gt;
                &lt;a href=&quot;https://folio-org.atlassian.net/browse/CIRCSTORE-16&quot; class=&quot;jira-issue-macro-key issue-link&quot;  title=&quot;operator_id is missing in loan_history_table&quot; &gt;
            &lt;img class=&quot;icon&quot; src=&quot;https://folio-org.atlassian.net/rest/api/2/universal_avatar/view/type/issuetype/avatar/10322?size=medium&quot; /&gt;
            CIRCSTORE-16
        &lt;/a&gt;
                                                    &lt;span class=&quot;aui-lozenge aui-lozenge-subtle aui-lozenge-success jira-macro-single-issue-export-pdf&quot;&gt;Closed&lt;/span&gt;
            &lt;/span&gt;
.&lt;/p&gt;

&lt;p&gt;I think we need to be explicit (I realise that my previous example was also ambiguous &lt;img class=&quot;emoticon&quot; src=&quot;/images/icons/emoticons/sad.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt; ) and consistent. My understanding of previous conversations, is that there is an intent to refer to related records by &lt;tt&gt;id&lt;/tt&gt; (and there is ongoing efforts in this space to do this for users), so I think we need to be especially clear if we want to do something different with metadata (we might, as a consequence of ID is that we would likely never want to ever delete a user from the system, though we might have already decided on this constraint).&lt;/p&gt;

&lt;p&gt;Maybe we need a convention when we reference another record, that makes it explicit what property the reference is for? For example createdUsername (I didn&apos;t want to do createdUserUsername) would refer to the the user who created the record by the username, whereas createdUserId would refer to the user who created the record by the ID. &lt;/p&gt;

&lt;p&gt;Alternatively, if we go with createdUser, then I think we need to be explicit in our description of the property what this should contain.&lt;/p&gt;</comment>
                                                            <comment id="192080" author="63e2a2771b13d42998e4e706" created="Thu, 27 Jul 2017 12:10:20 +0000"  >&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=712020%3A32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; class=&quot;user-hover&quot; rel=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; data-account-id=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; accountid=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; rel=&quot;noreferrer&quot;&gt;shale99&lt;/a&gt; &lt;/p&gt;

&lt;p&gt;In reference to the define comment about operator. I&apos;m wondering if the &lt;tt&gt;operatorId&lt;/tt&gt; property (discussed for loans and requests) is redundant when we have the &lt;tt&gt;updatedByUser&lt;/tt&gt; (or whatever we decide is appropriate) property in the &lt;tt&gt;metadata&lt;/tt&gt; object, or whether we want to define both?&lt;/p&gt;</comment>
                                                            <comment id="192081" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Thu, 27 Jul 2017 12:14:15 +0000"  >&lt;p&gt;it is,  this info can basically become part of all records we chose , so that we can have this type of functionality almost built into all record types we decide . the naming will also be consistent so that the ui doesnt have to do anything different &lt;/p&gt;</comment>
                                                            <comment id="192082" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Thu, 27 Jul 2017 12:25:34 +0000"  >&lt;p&gt;my thinking on this is that these two types (loans, requests) are 2 of many types that will need this info - i can imagine many types of records needing to track the dates and users making changes - so this is a generic baseline for this type of info that we can easily add to others in the future if needed in a standardized way&lt;/p&gt;</comment>
                                                            <comment id="192083" author="63e2a2771b13d42998e4e706" created="Thu, 27 Jul 2017 15:17:14 +0000"  >&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=712020%3A32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; class=&quot;user-hover&quot; rel=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; data-account-id=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; accountid=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; rel=&quot;noreferrer&quot;&gt;shale99&lt;/a&gt; &lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3Ab8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; class=&quot;user-hover&quot; rel=&quot;557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; data-account-id=&quot;557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; accountid=&quot;557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; rel=&quot;noreferrer&quot;&gt;Jakub Skoczen&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Following the conversation in today&apos;s meeting, &lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3Ab8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; class=&quot;user-hover&quot; rel=&quot;557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; data-account-id=&quot;557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; accountid=&quot;557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; rel=&quot;noreferrer&quot;&gt;Jakub Skoczen&lt;/a&gt; asked me to put together a schema (to put in the shared schemas).&lt;/p&gt;

&lt;p&gt;We discussed that the ID would be the primary way of referencing the user and having an optional username for both created and updated, that would be populated when available. I&apos;ve also incorporated feedback on the requests issue to use a pattern for the IDs, to increase confidence that they are UUIDs.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;
{
  &lt;span class=&quot;code-quote&quot;&gt;&quot;$schema&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;http:&lt;span class=&quot;code-comment&quot;&gt;//json-schema.org/draft-04/schema#&quot;&lt;/span&gt;,
&lt;/span&gt;  &lt;span class=&quot;code-quote&quot;&gt;&quot;title&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;Metadata Schema&quot;&lt;/span&gt;,
  &lt;span class=&quot;code-quote&quot;&gt;&quot;type&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;object&quot;&lt;/span&gt;,
  &lt;span class=&quot;code-quote&quot;&gt;&quot;properties&quot;&lt;/span&gt;: {
    &lt;span class=&quot;code-quote&quot;&gt;&quot;createdDate&quot;&lt;/span&gt;: {
      &lt;span class=&quot;code-quote&quot;&gt;&quot;description&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;Date and time when the record was created&quot;&lt;/span&gt;,
      &lt;span class=&quot;code-quote&quot;&gt;&quot;type&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;string&quot;&lt;/span&gt;,
      &lt;span class=&quot;code-quote&quot;&gt;&quot;format&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;date-time&quot;&lt;/span&gt;
    },
    &lt;span class=&quot;code-quote&quot;&gt;&quot;createdByUserId&quot;&lt;/span&gt;: {
      &lt;span class=&quot;code-quote&quot;&gt;&quot;description&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;ID of the user who created the record&quot;&lt;/span&gt;,
      &lt;span class=&quot;code-quote&quot;&gt;&quot;type&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;string&quot;&lt;/span&gt;,
      &lt;span class=&quot;code-quote&quot;&gt;&quot;pattern&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;^[a-f0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}$&quot;&lt;/span&gt;
    },
    &lt;span class=&quot;code-quote&quot;&gt;&quot;createdByUsername&quot;&lt;/span&gt;: {
      &lt;span class=&quot;code-quote&quot;&gt;&quot;description&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;Username of the user who created the record (when available)&quot;&lt;/span&gt;,
      &lt;span class=&quot;code-quote&quot;&gt;&quot;type&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;string&quot;&lt;/span&gt;
    },
    &lt;span class=&quot;code-quote&quot;&gt;&quot;updatedDate&quot;&lt;/span&gt;: {
      &lt;span class=&quot;code-quote&quot;&gt;&quot;description&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;Date and time when the record was last updated&quot;&lt;/span&gt;,
      &lt;span class=&quot;code-quote&quot;&gt;&quot;type&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;string&quot;&lt;/span&gt;,
      &lt;span class=&quot;code-quote&quot;&gt;&quot;format&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;date-time&quot;&lt;/span&gt;
    },
    &lt;span class=&quot;code-quote&quot;&gt;&quot;updatedByUserId&quot;&lt;/span&gt;: {
      &lt;span class=&quot;code-quote&quot;&gt;&quot;description&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;ID of the user who last updated the record&quot;&lt;/span&gt;,
      &lt;span class=&quot;code-quote&quot;&gt;&quot;type&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;string&quot;&lt;/span&gt;,
      &lt;span class=&quot;code-quote&quot;&gt;&quot;pattern&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;^[a-f0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}$&quot;&lt;/span&gt;
    },
    &lt;span class=&quot;code-quote&quot;&gt;&quot;updatedByUsername&quot;&lt;/span&gt;: {
      &lt;span class=&quot;code-quote&quot;&gt;&quot;description&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;Username of the user who last updated the record (when available)&quot;&lt;/span&gt;,
      &lt;span class=&quot;code-quote&quot;&gt;&quot;type&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;string&quot;&lt;/span&gt;
    }
  },
  &lt;span class=&quot;code-quote&quot;&gt;&quot;additionalProperties&quot;&lt;/span&gt;: &lt;span class=&quot;code-keyword&quot;&gt;false&lt;/span&gt;,
  &lt;span class=&quot;code-quote&quot;&gt;&quot;required&quot;&lt;/span&gt;: [
    &lt;span class=&quot;code-quote&quot;&gt;&quot;createdDate&quot;&lt;/span&gt;,
    &lt;span class=&quot;code-quote&quot;&gt;&quot;createdByUserId&quot;&lt;/span&gt;
  ]
}
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;An example being:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;
{
  &lt;span class=&quot;code-quote&quot;&gt;&quot;createdDate&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;2017-07-22T11:22:07Z&quot;&lt;/span&gt;,
  &lt;span class=&quot;code-quote&quot;&gt;&quot;createdByUserId&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;dee12548-9cee-45fa-bbae-675c1cc0ce3b&quot;&lt;/span&gt;,
  &lt;span class=&quot;code-quote&quot;&gt;&quot;createdByUsername&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;jaynesmith&quot;&lt;/span&gt;,
  &lt;span class=&quot;code-quote&quot;&gt;&quot;updatedDate&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;2017-07-27T13:28:54Z&quot;&lt;/span&gt;,
  &lt;span class=&quot;code-quote&quot;&gt;&quot;updatedByUserId&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;695540df-cf63-4c67-91c1-d8746920d1dd&quot;&lt;/span&gt;,
  &lt;span class=&quot;code-quote&quot;&gt;&quot;updatedByUsername&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;robertjones&quot;&lt;/span&gt;
}
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;An alternative could be to nest the updated and created aspects:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;
{
  &lt;span class=&quot;code-quote&quot;&gt;&quot;created&quot;&lt;/span&gt;: {
    &lt;span class=&quot;code-quote&quot;&gt;&quot;date&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;2017-07-22T11:22:07Z&quot;&lt;/span&gt;,
    &lt;span class=&quot;code-quote&quot;&gt;&quot;byUserId&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;dee12548-9cee-45fa-bbae-675c1cc0ce3b&quot;&lt;/span&gt;,
    &lt;span class=&quot;code-quote&quot;&gt;&quot;byUsername&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;jaynesmith&quot;&lt;/span&gt;
  },
  &lt;span class=&quot;code-quote&quot;&gt;&quot;updated&quot;&lt;/span&gt;: {
    &lt;span class=&quot;code-quote&quot;&gt;&quot;date&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;2017-07-27T13:28:54Z&quot;&lt;/span&gt;,
    &lt;span class=&quot;code-quote&quot;&gt;&quot;byUserId&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;695540df-cf63-4c67-91c1-d8746920d1dd&quot;&lt;/span&gt;,
    &lt;span class=&quot;code-quote&quot;&gt;&quot;byUsername&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;robertjones&quot;&lt;/span&gt;
  }
}
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Is now a good time to consider records created / updated by systems / batch processes etc, or is reasonable to assume that they will be executed within the context of a user?&lt;/p&gt;

&lt;p&gt;Thoughts and feedback welcome.&lt;/p&gt;</comment>
                                                            <comment id="192084" author="5bffed52a1b46046f530c8f7" created="Thu, 27 Jul 2017 15:20:48 +0000"  >&lt;p&gt;&lt;em&gt;If&lt;/em&gt; you&apos;re going to have a record with a nested structure, surely you&apos;d want to go the whole hog?&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;
{
  &lt;span class=&quot;code-quote&quot;&gt;&quot;created&quot;&lt;/span&gt;: {
    &lt;span class=&quot;code-quote&quot;&gt;&quot;date&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;2017-07-22T11:22:07Z&quot;&lt;/span&gt;,
    &lt;span class=&quot;code-quote&quot;&gt;&quot;user&quot;&lt;/span&gt;: {
      &lt;span class=&quot;code-quote&quot;&gt;&quot;id&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;dee12548-9cee-45fa-bbae-675c1cc0ce3b&quot;&lt;/span&gt;,
      &lt;span class=&quot;code-quote&quot;&gt;&quot;name&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;jaynesmith&quot;&lt;/span&gt;
    }
  },
  &lt;span class=&quot;code-quote&quot;&gt;&quot;updated&quot;&lt;/span&gt;: {
    &lt;span class=&quot;code-quote&quot;&gt;&quot;date&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;2017-07-27T13:28:54Z&quot;&lt;/span&gt;,
    &lt;span class=&quot;code-quote&quot;&gt;&quot;user&quot;&lt;/span&gt;: {
      &lt;span class=&quot;code-quote&quot;&gt;&quot;id&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;695540df-cf63-4c67-91c1-d8746920d1dd&quot;&lt;/span&gt;,
      &lt;span class=&quot;code-quote&quot;&gt;&quot;name&quot;&lt;/span&gt;: &lt;span class=&quot;code-quote&quot;&gt;&quot;robertjones&quot;&lt;/span&gt;
    }
  }
}
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                                                            <comment id="192085" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Thu, 27 Jul 2017 16:12:59 +0000"  >&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=63e2a2771b13d42998e4e706&quot; class=&quot;user-hover&quot; rel=&quot;63e2a2771b13d42998e4e706&quot; data-account-id=&quot;63e2a2771b13d42998e4e706&quot; accountid=&quot;63e2a2771b13d42998e4e706&quot; rel=&quot;noreferrer&quot;&gt;Marc Johnson&lt;/a&gt; - &lt;br/&gt;
1. a question - all of the ids are across the board uuids but do not contain a pattern (in all of our schemas) - this is enforced today by declaring the id field as a uuid in the database and this is enforced there - are we making a change to all ids of all schemas? - what is the purpose of doing it here ? or is this a first step ? - the ids in the metadata schema will be enforced by the db in any case. i am asking because this is something that will be auto-populated along with the dates by the server / database - this will not be input passed in by the client (this is more of a read only schema) - i would actually prefer to indicate the date-time format so that clients are aware of the format they will be receiving the date in - as this is something they will need to parse / display - i assume the userid will be either used as a straight lookup to retrieve the username or display the username if one exists. I have no problem with the pattern - just wondering if this should be done across the board to be consistent - or not at all - in order to give id flexibility (if that is at all needed)&lt;br/&gt;
2. i have no preference about whether it is two sections or one&lt;br/&gt;
3. since the metadata is really server / db generated , if we indicate required fields in the metadata it must become optional and not required - probably just stating the obvious here. the purpose of the required fields is to indicate that the server will definitely be passing these? &lt;/p&gt;</comment>
                                                            <comment id="192086" author="63e2a2771b13d42998e4e706" created="Fri, 28 Jul 2017 09:44:15 +0000"  >&lt;p&gt;@shale Thanks for your thoughts, I&apos;ll try to address them.&lt;/p&gt;

&lt;p&gt;&lt;b&gt;UUID pattern&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;I am crossing the streams a little here and conflating multiple changes. The interest in validating that &lt;tt&gt;id&lt;/tt&gt; properties are UUIDs came from a request from &lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3Ab8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; class=&quot;user-hover&quot; rel=&quot;557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; data-account-id=&quot;557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; accountid=&quot;557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; rel=&quot;noreferrer&quot;&gt;Jakub Skoczen&lt;/a&gt; : &lt;a href=&quot;https://folio-org.atlassian.net/browse/UIREQ-1?focusedCommentId=58767&amp;amp;page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&quot; class=&quot;external-link&quot; rel=&quot;nofollow noreferrer&quot;&gt;https://folio-org.atlassian.net/browse/UIREQ-1?focusedCommentId=58767&amp;amp;page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I believe the intention is to eventually use this (or similar pattern) for all &lt;tt&gt;id&lt;/tt&gt; properties. It seemed to me like this and requests were a reasonable place to start, we can easily omit it here for the time being (given the way we share schema, controlled upgrades of common schema is challenging).&lt;/p&gt;

&lt;p&gt;&lt;b&gt;User ID and Username&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;My understanding from the conversation on yesterday&apos;s call was that we wanted references to a user to be by &lt;tt&gt;id&lt;/tt&gt;. Yet it could be useful (where possible), to also include an (optional) property containing the username which could help with easier presentation and diagnostics.&lt;/p&gt;

&lt;p&gt;&lt;b&gt;Date Format&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;Personally I find the semantic expression of formats preferable over patterns. Being a profile of ISO8601 I believe clients can comfortably parse this (most seem to parse it as though it is the full spectrum of ISO8601). If we want to further constrain this to always UTC we could do so with a compatible pattern.&lt;/p&gt;

&lt;p&gt;&lt;b&gt;Required Properties&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;It is true that the metadata object will likely be server generated, which means that the property in the parent object will likely need to be optional, as we share schema between read and write requests/responses. This does mean that the required properties within it are therefore mostly for documentation purposes (unless a client chose to validate a response from a server, for example).&lt;/p&gt;

&lt;p&gt;I left the updated properties optional as I wanted to leave it open to those properties only being provided after the first update (one advantage of the nesting is that it allows this to be more explicit in the schema).&lt;/p&gt;</comment>
                                                            <comment id="192087" author="5bffed52a1b46046f530c8f7" created="Fri, 28 Jul 2017 09:55:34 +0000"  >&lt;p&gt;Yes, validating UUID by regexp is a nice incremental step.&lt;br/&gt;
Yes, including userName as well as userId will make this &lt;em&gt;much&lt;/em&gt; more useful.&lt;br/&gt;
Yes, ISO 8601 is absolutely the way to go for dates.&lt;/p&gt;</comment>
                                                            <comment id="192088" author="557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d" created="Fri, 28 Jul 2017 13:00:30 +0000"  >&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=63e2a2771b13d42998e4e706&quot; class=&quot;user-hover&quot; rel=&quot;63e2a2771b13d42998e4e706&quot; data-account-id=&quot;63e2a2771b13d42998e4e706&quot; accountid=&quot;63e2a2771b13d42998e4e706&quot; rel=&quot;noreferrer&quot;&gt;Marc Johnson&lt;/a&gt; I have to say I prefer your flat structure rather than nesting under &quot;creator&quot;, etc. It&apos;s more context-free and we would be already nesting this per endpoint using &quot;metadata&quot; or similar.&lt;/p&gt;

&lt;p&gt;For batch processes, assume that those are always going to be executed by a system user, so same fields apply.&lt;/p&gt;

&lt;p&gt;Logging in username will be useful, although it has to be clear that this is &quot;historical&quot; information, (as the username may be changed) and the up-to-date user info needs to be read from the user record referred to by ID.&lt;/p&gt;

&lt;p&gt;Agree on date-time and UUID regex.&lt;/p&gt;</comment>
                                                            <comment id="192089" author="63e2a2771b13d42998e4e706" created="Fri, 28 Jul 2017 13:18:36 +0000"  >&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=712020%3A32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; class=&quot;user-hover&quot; rel=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; data-account-id=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; accountid=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; rel=&quot;noreferrer&quot;&gt;shale99&lt;/a&gt; &lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3Ab8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; class=&quot;user-hover&quot; rel=&quot;557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; data-account-id=&quot;557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; accountid=&quot;557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; rel=&quot;noreferrer&quot;&gt;Jakub Skoczen&lt;/a&gt; &lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=5bffed52a1b46046f530c8f7&quot; class=&quot;user-hover&quot; rel=&quot;5bffed52a1b46046f530c8f7&quot; data-account-id=&quot;5bffed52a1b46046f530c8f7&quot; accountid=&quot;5bffed52a1b46046f530c8f7&quot; rel=&quot;noreferrer&quot;&gt;Mike Taylor&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Ok, so I&apos;m going to go ahead and create the schema (keeping it flat) in the shared raml git repository. Let me know if there are any immediate concerns.&lt;/p&gt;</comment>
                                                            <comment id="192090" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Fri, 28 Jul 2017 13:20:01 +0000"  >&lt;p&gt;ok, so my understnading is that we are starting to indicate patterns for the id fields across the board - and this is a first step&lt;/p&gt;

&lt;p&gt;right now, rmb supports iso8601 and not a profile of iso8601 - that is why i prefer the regex on the date rather than date-time - so that clients know exactly what they are getting back unless we are changing the rmb support for dates, which i rather not get into&lt;/p&gt;

&lt;p&gt;the issue with username - which i originally thought was the way to go as (i thought mistakenly) - it was unique and never changing - is that - if a username is changed (which seems to be something we are supporting) - the ui can not rely on this field any more for display - and should always look up via the uuid - unless the username update will update the history table as well (this gets complicated as its cross module changes)&lt;/p&gt;</comment>
                                                            <comment id="192091" author="63e2a2771b13d42998e4e706" created="Fri, 28 Jul 2017 13:24:12 +0000"  >&lt;p&gt;One thing we still need to consider is what the server response to a request made with this metadata present should be:&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;Ignore the &lt;tt&gt;metadata&lt;/tt&gt; property entirely, wholly replacing them with server derived state&lt;/li&gt;
	&lt;li&gt;Reject the request citing that clients should not provide the &lt;tt&gt;metadata&lt;/tt&gt; property&lt;/li&gt;
&lt;/ul&gt;
</comment>
                                                            <comment id="192092" author="63e2a2771b13d42998e4e706" created="Fri, 28 Jul 2017 13:31:24 +0000"  >&lt;p&gt;I&apos;ve pushed this on a branch.&lt;/p&gt;

&lt;p&gt;The schema is available to look at here: &lt;a href=&quot;https://github.com/folio-org/raml/blob/FOLIO-592-metadata-schema/schemas/metadata.schema&quot; class=&quot;external-link&quot; rel=&quot;nofollow noreferrer&quot;&gt;https://github.com/folio-org/raml/blob/FOLIO-592-metadata-schema/schemas/metadata.schema&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I&apos;d like &lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=61cd0ca0bce5e00069e98be7&quot; class=&quot;user-hover&quot; rel=&quot;61cd0ca0bce5e00069e98be7&quot; data-account-id=&quot;61cd0ca0bce5e00069e98be7&quot; accountid=&quot;61cd0ca0bce5e00069e98be7&quot; rel=&quot;noreferrer&quot;&gt;David Crossley&lt;/a&gt; to take a look, with regards to 
    &lt;span class=&quot;jira-issue-macro resolved&quot; data-jira-key=&quot;RMB-30&quot; &gt;
                &lt;a href=&quot;https://folio-org.atlassian.net/browse/RMB-30&quot; class=&quot;jira-issue-macro-key issue-link&quot;  title=&quot;Trouble with a schema file referring to another schema in raml-util&quot; &gt;
            &lt;img class=&quot;icon&quot; src=&quot;https://folio-org.atlassian.net/rest/api/2/universal_avatar/view/type/issuetype/avatar/10318?size=medium&quot; /&gt;
            RMB-30
        &lt;/a&gt;
                                                    &lt;span class=&quot;aui-lozenge aui-lozenge-subtle aui-lozenge-success jira-macro-single-issue-export-pdf&quot;&gt;Closed&lt;/span&gt;
            &lt;/span&gt;
, about whether this location is ok from the perspective of including it in schema below it in the hierarchy.&lt;/p&gt;</comment>
                                                            <comment id="192093" author="63e2a2771b13d42998e4e706" created="Fri, 28 Jul 2017 13:48:49 +0000"  >&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=712020%3A32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; class=&quot;user-hover&quot; rel=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; data-account-id=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; accountid=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; rel=&quot;noreferrer&quot;&gt;shale99&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I regard an ISO8601 profile as a more specific subset of the standard (that supports a wide variety of representations). My understanding of proposing a pattern regular expression, is to define our own profile, is that a sensible expression of your intent?&lt;/p&gt;

&lt;p&gt;Are you proposing that, based upon your new understanding of the potential for a username to change, that the &lt;tt&gt;createdByUsername&lt;/tt&gt; and &lt;tt&gt;updatedByUsername&lt;/tt&gt; properties are no longer useful?&lt;/p&gt;</comment>
                                                            <comment id="192094" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Fri, 28 Jul 2017 14:04:59 +0000"  >&lt;blockquote&gt;&lt;p&gt;I regard an ISO8601 profile as a more specific subset of the standard (that supports a wide variety of representations). My understanding of proposing a pattern regular expression, is to define our own profile, is that a sensible expression of your intent?&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;yes, i think we should define an iso8601 profile format so that there are no surprises - for example, lets take last weeks example - of setting &#8220;2017-04-20T07:21:45.000Z&#8221; and getting back &#8220;2017-04-20T07:21:45.000+0000&quot; - if we are ok with this - that the date format is controlled by the server but it is iso8601 conformant and not necessarily what is passed in. then date-time works for me as well&lt;/p&gt;

&lt;blockquote&gt;&lt;p&gt;Are you proposing that, based upon your new understanding of the potential for a username to change, that the createdByUsername and updatedByUsername properties are no longer useful?&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;kind of yes, once a username is removed across the system and replaced by the uuid - and the username becomes a updateble field - i think its not as valuable to keep it around in different places in the system (especially to start displaying it in different modules) - it will be a real pain to start cleaning this up when customers encounter non existent usernames in different places in the system&lt;/p&gt;</comment>
                                                            <comment id="192095" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Sun, 30 Jul 2017 15:14:18 +0000"  >&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=712020%3A32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; class=&quot;user-hover&quot; rel=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; data-account-id=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; accountid=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; rel=&quot;noreferrer&quot;&gt;shale99&lt;/a&gt; I moved your comment to 
    &lt;span class=&quot;jira-issue-macro resolved&quot; data-jira-key=&quot;RMB-48&quot; &gt;
                &lt;a href=&quot;https://folio-org.atlassian.net/browse/RMB-48&quot; class=&quot;jira-issue-macro-key issue-link&quot;  title=&quot;implement handling of meta-data section in RMB&quot; &gt;
            &lt;img class=&quot;icon&quot; src=&quot;https://folio-org.atlassian.net/rest/api/2/universal_avatar/view/type/issuetype/avatar/10318?size=medium&quot; /&gt;
            RMB-48
        &lt;/a&gt;
                                                    &lt;span class=&quot;aui-lozenge aui-lozenge-subtle aui-lozenge-success jira-macro-single-issue-export-pdf&quot;&gt;Closed&lt;/span&gt;
            &lt;/span&gt;
, let&apos;s keep this one about schema defintion&lt;/p&gt;</comment>
                                                            <comment id="192096" author="557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d" created="Mon, 31 Jul 2017 09:57:37 +0000"  >&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=712020%3A32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; class=&quot;user-hover&quot; rel=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; data-account-id=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; accountid=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; rel=&quot;noreferrer&quot;&gt;shale99&lt;/a&gt; Are you concerned that the format of the date-time would not be letter by letter what the client specified? E.g that the timezone info can be reported differently? I think this is totally OK, any client needs to be able to sensibly parse the RFC3339 date, which is already way more constrained compared to standard ISO8601. It&apos;s not rocket science. So I would stick with that.&lt;/p&gt;

&lt;p&gt;I would still keep the readable username in the meta-data section, for convenience of annotating log-lines, etc. &lt;/p&gt;</comment>
                                                            <comment id="192097" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Mon, 31 Jul 2017 10:39:43 +0000"  >&lt;p&gt;1. yes, this was my first comment - it needs to be clear that whatever the client sends in - it needs to be understood that this is not necessarily what they will get back - (there is one system date format or at least i believe the server should work with / save / parse with one date format) - if we are ok with the clients getting the variations then this is ok by me.&lt;br/&gt;
--&amp;gt; take jackson for example - the rfc indicates that it may be possible to pass in a lower case &apos;t&apos; in the format - however, jackson will fail to parse in such a case - so we need to indicate this - also there are some variances (i see only one milli is needed by the rfc - but i will check - i am pretty sure jackson will fail to parse that as well) - and all of rmb json processing is jackson based - just something to be aware of if we dont indicate a single supported format&lt;/p&gt;

&lt;p&gt;2. as for the user name - honestly,not crazy about this - once username becomes a mutable field - then a minute after it is logged it can be changed and become irrelevant - so the ui cannot use this anymore for display. this means a lookup based on the uuid is needed to get reliable data about the updater / creator so then the username loses its meaning - since you will always need a uuid lookup to get the username - but if we are sure about this i can add it as i left it out.&lt;/p&gt;</comment>
                                                            <comment id="192098" author="61cd0ca0bce5e00069e98be7" created="Wed, 2 Aug 2017 03:04:26 +0000"  >&lt;p&gt;Marc asked above (28/Jul/17) whether the placement of this metadata schema will suffer from the effects described in 
    &lt;span class=&quot;jira-issue-macro resolved&quot; data-jira-key=&quot;RMB-30&quot; &gt;
                &lt;a href=&quot;https://folio-org.atlassian.net/browse/RMB-30&quot; class=&quot;jira-issue-macro-key issue-link&quot;  title=&quot;Trouble with a schema file referring to another schema in raml-util&quot; &gt;
            &lt;img class=&quot;icon&quot; src=&quot;https://folio-org.atlassian.net/rest/api/2/universal_avatar/view/type/issuetype/avatar/10318?size=medium&quot; /&gt;
            RMB-30
        &lt;/a&gt;
                                                    &lt;span class=&quot;aui-lozenge aui-lozenge-subtle aui-lozenge-success jira-macro-single-issue-export-pdf&quot;&gt;Closed&lt;/span&gt;
            &lt;/span&gt;
.&lt;/p&gt;

&lt;p&gt;I tested it today on mod-users and mod-configuration.&lt;/p&gt;

&lt;p&gt;Unfortunately, yes it does.&lt;/p&gt;

&lt;p&gt;As explained at 
    &lt;span class=&quot;jira-issue-macro resolved&quot; data-jira-key=&quot;RMB-30&quot; &gt;
                &lt;a href=&quot;https://folio-org.atlassian.net/browse/RMB-30&quot; class=&quot;jira-issue-macro-key issue-link&quot;  title=&quot;Trouble with a schema file referring to another schema in raml-util&quot; &gt;
            &lt;img class=&quot;icon&quot; src=&quot;https://folio-org.atlassian.net/rest/api/2/universal_avatar/view/type/issuetype/avatar/10318?size=medium&quot; /&gt;
            RMB-30
        &lt;/a&gt;
                                                    &lt;span class=&quot;aui-lozenge aui-lozenge-subtle aui-lozenge-success jira-macro-single-issue-export-pdf&quot;&gt;Closed&lt;/span&gt;
            &lt;/span&gt;
, the build is successful. However due to the &quot;../&quot; path in the $ref in the parent schema, copies of &quot;metadata.schema&quot; remain at &quot;/tmp/metadata.schema&quot; for the mod-users, and at &quot;/tmp/raml-util/schemas/metadata.schema&quot; for mod-configuration.&lt;/p&gt;

&lt;p&gt;There is only one set of dot-dots in the path, so at least the build is successful.&lt;/p&gt;</comment>
                                                            <comment id="192099" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Wed, 2 Aug 2017 05:04:42 +0000"  >&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=61cd0ca0bce5e00069e98be7&quot; class=&quot;user-hover&quot; rel=&quot;61cd0ca0bce5e00069e98be7&quot; data-account-id=&quot;61cd0ca0bce5e00069e98be7&quot; accountid=&quot;61cd0ca0bce5e00069e98be7&quot; rel=&quot;noreferrer&quot;&gt;David Crossley&lt;/a&gt; - the current issue is the leftovers that are not deleted, right?&lt;/p&gt;</comment>
                                                            <comment id="192100" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Wed, 2 Aug 2017 05:20:11 +0000"  >&lt;p&gt;In general, schemas such as the meta data schema will run into this situation since they are generic shared schemas placed in the raml-util/schemas dir, correct? we can open an issue on this and attempt a delete of such files from the /tmp dir by the rmb after the pojos are generated. &lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=61cd0ca0bce5e00069e98be7&quot; class=&quot;user-hover&quot; rel=&quot;61cd0ca0bce5e00069e98be7&quot; data-account-id=&quot;61cd0ca0bce5e00069e98be7&quot; accountid=&quot;61cd0ca0bce5e00069e98be7&quot; rel=&quot;noreferrer&quot;&gt;David Crossley&lt;/a&gt; - is there something else that can be done here or can we merge this in?&lt;/p&gt;</comment>
                                                            <comment id="192101" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Wed, 2 Aug 2017 06:03:41 +0000"  >&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=61cd0ca0bce5e00069e98be7&quot; class=&quot;user-hover&quot; rel=&quot;61cd0ca0bce5e00069e98be7&quot; data-account-id=&quot;61cd0ca0bce5e00069e98be7&quot; accountid=&quot;61cd0ca0bce5e00069e98be7&quot; rel=&quot;noreferrer&quot;&gt;David Crossley&lt;/a&gt; , &lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=63e2a2771b13d42998e4e706&quot; class=&quot;user-hover&quot; rel=&quot;63e2a2771b13d42998e4e706&quot; data-account-id=&quot;63e2a2771b13d42998e4e706&quot; accountid=&quot;63e2a2771b13d42998e4e706&quot; rel=&quot;noreferrer&quot;&gt;Marc Johnson&lt;/a&gt; - i have merged this as it was a blocker for me to continue with the implementation. As discussed, David will be opening an issue on rmb , to delete /tmp schemas after the pojo generation step&lt;/p&gt;</comment>
                                                            <comment id="192102" author="61cd0ca0bce5e00069e98be7" created="Wed, 2 Aug 2017 07:14:52 +0000"  >&lt;p&gt;That cleanup idea is 
    &lt;span class=&quot;jira-issue-macro resolved&quot; data-jira-key=&quot;RMB-50&quot; &gt;
                &lt;a href=&quot;https://folio-org.atlassian.net/browse/RMB-50&quot; class=&quot;jira-issue-macro-key issue-link&quot;  title=&quot;Clean the temp space after build to remove remnants of schema processing&quot; &gt;
            &lt;img class=&quot;icon&quot; src=&quot;https://folio-org.atlassian.net/rest/api/2/universal_avatar/view/type/issuetype/avatar/10318?size=medium&quot; /&gt;
            RMB-50
        &lt;/a&gt;
                                                    &lt;span class=&quot;aui-lozenge aui-lozenge-subtle aui-lozenge-success jira-macro-single-issue-export-pdf&quot;&gt;Closed&lt;/span&gt;
            &lt;/span&gt;
.&lt;/p&gt;

&lt;p&gt;In general, yes the shared schema area. In particular, when any schema has $ref with dot-dots, then there will be temp remnants. Any more than one set of dot-dots will be broken.&lt;/p&gt;</comment>
                                                            <comment id="192103" author="63e2a2771b13d42998e4e706" created="Wed, 2 Aug 2017 16:29:36 +0000"  >&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=712020%3A32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; class=&quot;user-hover&quot; rel=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; data-account-id=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; accountid=&quot;712020:32bb56ac-50e7-4787-b4af-ed3089d9401c&quot; rel=&quot;noreferrer&quot;&gt;shale99&lt;/a&gt; &lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3Ab8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; class=&quot;user-hover&quot; rel=&quot;557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; data-account-id=&quot;557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; accountid=&quot;557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d&quot; rel=&quot;noreferrer&quot;&gt;Jakub Skoczen&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;What have we decided to do for state altering requests that have the metadata section present? &lt;/p&gt;

&lt;p&gt;Either:&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;Ignore the metadata property entirely, wholly replacing it with server derived state&lt;/li&gt;
	&lt;li&gt;Reject the request citing that clients should not provide the metadata property&lt;/li&gt;
&lt;/ul&gt;
</comment>
                                                            <comment id="192104" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Wed, 2 Aug 2017 17:37:18 +0000"  >&lt;p&gt;right now it is ignored and replaced by the server side generated info every time - meaning the client does not need to send it, but if the client does, the section will be ignored but the request will not fail. Not sure we closed this issue - ignoring gives a bit more flexibility as it does not require the client to parse out sections of the json before sending (for example an update) - and if the info is included, the request wont fail it will just be ignored.  this appriach gives a bit more flexibility but may be a bit less clean. &lt;/p&gt;</comment>
                                                            <comment id="192105" author="712020:32bb56ac-50e7-4787-b4af-ed3089d9401c" created="Thu, 3 Aug 2017 11:34:52 +0000"  >&lt;p&gt;pull request Folio 592&lt;br/&gt;
mod-circ-storage - temporarily depending on rmb 13.1.0-snapshot - will release rmb today and update pom&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10000">
                    <name>Blocks</name>
                                            <outwardlinks description="blocks">
                                        <issuelink>
            <issuekey id="29687">CIRCSTORE-16</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="56706">RMB-48</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is blocked by">
                                        <issuelink>
            <issuekey id="56721">RMB-30</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10003">
                    <name>Relates</name>
                                            <outwardlinks description="relates to">
                                        <issuelink>
            <issuekey id="67521">MODUSERS-23</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="29683">CIRCSTORE-14</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="56707">RMB-50</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="relates to">
                                        <issuelink>
            <issuekey id="25659">UIREQ-1</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="29318">UX-39</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="80433">FOLIO-972</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="67581">MODUSERS-16</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                <customfield id="customfield_10000" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummarycf">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_10019" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>0|hzxnt3:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_10020" key="com.pyxis.greenhopper.jira:gh-sprint">
                        <customfieldname>Sprint</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_10024" key="com.atlassian.jira.ext.charting:firstresponsedate">
                        <customfieldname>[CHART] Date of First Response</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Tue, 23 May 2017 12:04:30 +0000</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10025" key="com.atlassian.jira.ext.charting:timeinstatus">
                        <customfieldname>[CHART] Time in Status</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                    </customfields>
    </item>
</channel>
</rss>