<!-- 
RSS generated by JIRA (1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d) at Thu Feb 08 23:07:27 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-664] Get feedback on Bulk User Import prerequisites</title>
                <link>https://folio-org.atlassian.net/browse/FOLIO-664</link>
                <project id="10290" key="FOLIO">FOLIO</project>
                    <description>&lt;p&gt;Bulk user import will be realized using institution made scripts which are doing institution specific data retrieval, transformation and calling the FOLIO API to update the users database. During the UM-SIG meetings it was identified that FOLIO&apos;s &lt;tt&gt;mod-users&lt;/tt&gt; have existing API endpoints which can support the bulk user import functionality. But there are some mismatches which need to be solved:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;User import action needs to be an atomic / transactional operation and modifications needs to be rolled back if an issue occurs. The user insert endpoint is only inserting base user data, additional structures like address entities have to be added in a separate call. If an address insertion fails, the script have to manually rollback changes which is cumbersome to do.&lt;/li&gt;
	&lt;li&gt;The insert API call (correctly) fails, if the user already exists in the system. However in the script there should be a way to do an &quot;update-if-exists&quot; operation if some fields of an existing user changes in the source system. Currently this can only be done, by doing a separate query to check if the user already exists and instead of the POST endpoint, the PUT endpoint should be called. This again adds complexity to the script.&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;I see two ways to solve this:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;Create an additional &lt;em&gt;&#8220;insert-or-update-with-all-user-data&#8221;&lt;/em&gt; API call which atomically inserts or updates a user with each and every field. This solve the issue, however it&apos;s against the REST principles.&lt;/li&gt;
	&lt;li&gt;Leave the existing REST calls intact (creating no duplicates) but add transaction opening/committing/rollback capability to the existing REST API. As an example how this can be done, see Fedora&apos;s REST API Transaction support: &lt;a href=&quot;https://wiki.duraspace.org/display/FEDORA40/RESTful+HTTP+API+-+Transactions&quot; class=&quot;external-link&quot; rel=&quot;nofollow noreferrer&quot;&gt;https://wiki.duraspace.org/display/FEDORA40/RESTful+HTTP+API+-+Transactions&lt;/a&gt; This might be also usable with other scenarios of the FOLIO REST API calls, not just &lt;tt&gt;mod-users&lt;/tt&gt;, but it&apos;s definitely a more complex thing to implement.&lt;/li&gt;
&lt;/ul&gt;
</description>
                <environment></environment>
        <key id="80208">FOLIO-664</key>
            <summary>Get feedback on Bulk User Import prerequisites</summary>
                <type id="10002" iconUrl="https://folio-org.atlassian.net/rest/api/2/universal_avatar/view/type/issuetype/avatar/10322?size=medium">New Feature</type>
                                            <priority id="10001" iconUrl="https://dev.folio.org/assets/jira-priority/jira-p2.svg">P2</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="5e1750638dfdd40ec489bf08">Katalin Lovagn&#233; Sz&#369;cs</assignee>
                                                                <reporter accountid="5e16e55ae3b48c0daa0f8727">Nagy Istv&#225;n</reporter>
                                    <labels>
                            <label>for-next-sprint</label>
                            <label>sprint16</label>
                            <label>sprint17</label>
                            <label>team1</label>
                    </labels>
                <created>Mon, 12 Jun 2017 14:07:17 +0000</created>
                <updated>Mon, 12 Nov 2018 14:23:35 +0000</updated>
                            <resolved>Mon, 10 Jul 2017 13:24:41 +0000</resolved>
                                                                        <due></due>
                            <votes>0</votes>
                                    <watches>7</watches>
                                                    <timespent seconds="28800">1 day</timespent>
                                <comments>
                                                            <comment id="188401" author="5c38e8d616ac1e4f7cbc660a" created="Wed, 14 Jun 2017 17:26:51 +0000"  >&lt;p&gt;How much special infrastructure do we need to support bulk user imports?&lt;/p&gt;

&lt;p&gt;Let&apos;s assume we can send a single POST request to add a given user to the system (likely this will need to be exposed by the mod-users-bl module, since a practical import is going to have to include permissions and login credentials information). It does not seem terribly prohibitive to me to need to make a single call per user that we&apos;re importing. Sure, the overhead is higher than some process that takes a single file containing multiple users, but it&apos;s the sort of thing that only needs to happen once in the lifetime if a given system.&lt;/p&gt;

&lt;p&gt;For dealing with pre-existing users, why not just pay attention to the failure response in the case of a failure. If you try to POST a new users and get a 422 (or maybe a 409?) then that tells the script that the user already exists. If need be, we can send a query request after the failed POST in order to verify this. Not terribly hard from a scripting standpoint.&lt;/p&gt;</comment>
                                                            <comment id="188405" author="557058:b8e64633-1f7c-402d-9caf-9959a5ba5d0d" created="Thu, 15 Jun 2017 11:37:22 +0000"  >&lt;p&gt;Yes, a single POST with user metadata (including related meta-data that is currently kept in seperate enpoints, like potentially contact) seems good enough for this.&lt;/p&gt;

&lt;p&gt;I think the try-catch approach that Kurt proposes sounds good. We can also extend the webservice with and &quot;addressable&quot; PUT &amp;#8211; if the ID for PUT is provided and user exists the user will get updated, if not it will be created with a given ID (I think some enpoints should already work like that). What&apos;s your thinking Kurt?&lt;/p&gt;</comment>
                                                            <comment id="188409" author="5e16e55ae3b48c0daa0f8727" created="Thu, 15 Jun 2017 12:29:49 +0000"  >&lt;p&gt;Signaling collision with HTTP error codes is good enough, and shouldn&apos;t be hard to handle. I&apos;m thinking that maybe we should supply some kind of example script skeletons anyway to demonstrate how an import tool will behave and to show use cases like updating an existing user.&lt;/p&gt;

&lt;p&gt;I have some basic experience with RAML. I guess it should be possible to merge the accepted JSON object structure of the import endpoint from different sub type definitions (like reusing the already defined address block). So you can minimize the issue of the data structures drifting away from each other by multiple API endpoints.&lt;/p&gt;

&lt;p&gt;I see one (actually not so small) issue with the &lt;em&gt;&quot;provide-every-user-data-in-one-object&quot;&lt;/em&gt; structure.&lt;br/&gt;
Let&apos;s say you are about to update a user which had two addresses previously, and you supply in the update just a single address. As far as i remember, address blocks&apos; don&apos;t have separate ID&apos;s, so you cannot explicitly specify which address you are referring to (but if it does, there might be other list fields which doesn&apos;t and the issue will be the same). How will FOLIO know if you meant to a) update one of the addresses b) reduce the address list to just one address c) it&apos;s a new address you are about to add?&lt;br/&gt;
Updating associated collections seems difficult. We can say, that if you would like to modify a collection field, you have to supply all elements and they will be replaced, but that still has issues with references. Existing objects might already referencing an older address entry and this link have to be kept.&lt;/p&gt;</comment>
                                                            <comment id="188411" author="5cf6c265e7d2310e9fc0c5ac" created="Fri, 16 Jun 2017 19:28:48 +0000"  >&lt;p&gt;I agree that the user creation and user updating should be separate: the former a POST and the latter a PUT. The proposal would be:&lt;/p&gt;
&lt;ol&gt;
	&lt;li&gt;Attempt a POST on the user&lt;/li&gt;
	&lt;li&gt;Check response code and see if user already exists&lt;/li&gt;
	&lt;li&gt;If user already exists then attempt a PUT operation instead.&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;But if step 2 returns a 4xx error code it won&apos;t be able to return the ID of the identified user. So the ID would not be available in step 3 to do an incremental update (if it becomes supported). The result would be to completely overwrite the existing user record.  Therefore the issue of not having an ID starts before associated collections and already exists with the user record.&lt;/p&gt;</comment>
                                                            <comment id="188412" author="5af5ed55244bc90a106063c7" created="Mon, 19 Jun 2017 08:58:32 +0000"  >&lt;blockquote&gt;&lt;p&gt;Let&apos;s say you are about to update a user which had two addresses previously, and you supply in the update just a single address. As far as i remember, address blocks&apos; don&apos;t have separate ID&apos;s, so you cannot explicitly specify which address you are referring to (but if it does, there might be other list fields which doesn&apos;t and the issue will be the same). How will FOLIO know if you meant to a) update one of the addresses b) reduce the address list to just one address c) it&apos;s a new address you are about to add?&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;In this scenario, I&apos;d think we can just assume that the address list would be reduced to just one address (your option b).  This seems like the simplest, workable option. &lt;/p&gt;</comment>
                                                            <comment id="188414" author="5e16e55ae3b48c0daa0f8727" created="Mon, 19 Jun 2017 09:56:07 +0000"  >&lt;p&gt;Even if we consider the b) option, how will the system know if the single address you just provided is &lt;br/&gt;
1) a 4th new address and the previous 3 should be deleted&lt;br/&gt;
2) it&apos;s an updated variant of one of the previous three, it&apos;s associations needs to be preserved and the other two should be deleted?&lt;/p&gt;

&lt;p&gt;By associations I mean that address might be eg. used in an existing loan as a retrieval address and we just cannot delete it. But we cannot update it either, because we don&apos;t have any specific ID like &quot;2nd address of the 1st user&quot; to refer to it explicitly.&lt;/p&gt;</comment>
                                                            <comment id="188416" author="5af5ed55244bc90a106063c7" created="Mon, 19 Jun 2017 10:41:12 +0000"  >&lt;p&gt;Oh, I see.  I don&apos;t actually know of any scenarios in which user addresses have &quot;associations&quot; in other objects.  Retrieval address doesn&apos;t make sense to me, as you wouldn&apos;t retrieve/pick up a loan at a user address (you&apos;d pick up at a library location). Addresses may be tied to notifications but my understanding is that email is, by far, the preferred method of communication with users.  If snail mail notifications are sent, we might just want to archive the notification itself or key details such as when and to where it was sent.  That way the address could be later removed without impacting the notification audit trail.  &lt;/p&gt;

&lt;p&gt;We probably should check with the SIG whether there are other associations for user addresses.  &lt;/p&gt;</comment>
                                                            <comment id="188417" author="5e1750638dfdd40ec489bf08" created="Wed, 21 Jun 2017 15:48:33 +0000"  >&lt;p&gt;We had a discussion about address updates on today&apos;s SIG meeting.&lt;/p&gt;

&lt;p&gt;The conclusion is that we should only update the addresses originally came from the external system. A user can have one address per address type which can be the identifier between the FOLIO data and the external system&apos;s data. Manually created addresses in FOLIO should not be updated from the external source. &lt;/p&gt;

&lt;p&gt;When an address is deleted in the external system, an empty or flagged (deleted) nested address object could be sent to FOLIO. &lt;/p&gt;

&lt;p&gt;While discussing the user update, a new idea came up: maybe we should ask the system first about the users to insert/update if they already exist in the system (e.g. by their external system id) and if so retrieve the id of the user so that an update action can be sent instead of a failing insert. Can we use the existing user search API for this purpose?&lt;/p&gt;</comment>
                                                            <comment id="188420" author="5c38e8d616ac1e4f7cbc660a" created="Wed, 21 Jun 2017 19:28:49 +0000"  >&lt;p&gt;To the extent of my knowledge, we are not currently tracking addresses as actual entities. Rather, they are simply sub-fields within the user record. Is there a use case that would require that addresses be treated as discrete objects and link to the user record by identifier?&lt;/p&gt;

&lt;p&gt;Regarding querying for IDs, it is certainly possible to query the user and get the ID if they exist. However, I think that if we do this for all users, we end up making a lot more requests than if we simply attempt to create and then take action after a failed create attempt.&lt;/p&gt;</comment>
                                                            <comment id="188421" author="5e1750638dfdd40ec489bf08" created="Thu, 22 Jun 2017 08:00:24 +0000"  >&lt;p&gt;Yes, we discussed the problem of changing and deleting address blocks originated from the external system. These should be distinguished from the ones that were manually added in FOLIO. That is why we thought about address types for an &quot;identifier&quot; to know which addresses should be updated, removed or left as is. Does that make sense to you?&lt;/p&gt;

&lt;p&gt;We talked about an option to check all user data in one query (not one per user). It came up because some systems cannot handle deltas but resend the whole user set every time and this would cause a lot of insert call to fail and fallback to update.&lt;/p&gt;</comment>
                                                            <comment id="188424" author="5e1750638dfdd40ec489bf08" created="Fri, 23 Jun 2017 11:04:05 +0000"  >&lt;p&gt;When importing users how the credentials should be treated? Do we want to import user passwords via the bulk import? Should we generate default passwords instead of importing them? &lt;/p&gt;

&lt;p&gt;What about SSO? How should we treat SSO user identifiers when importing user data?&lt;/p&gt;</comment>
                                                            <comment id="188426" author="5c38e8d616ac1e4f7cbc660a" created="Fri, 23 Jun 2017 13:46:56 +0000"  >&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=5e1750638dfdd40ec489bf08&quot; class=&quot;user-hover&quot; rel=&quot;5e1750638dfdd40ec489bf08&quot; data-account-id=&quot;5e1750638dfdd40ec489bf08&quot; accountid=&quot;5e1750638dfdd40ec489bf08&quot; rel=&quot;noreferrer&quot;&gt;Katalin Lovagn&#233; Sz&#369;cs&lt;/a&gt;: I think we have to plan for creating an endpoint in the Users Business Logic module that takes a composite record, as opposed to just one particular record.  So something could be posted like:&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;user&quot;&lt;/span&gt; : { &lt;span class=&quot;code-quote&quot;&gt;&quot;username&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;address&quot;&lt;/span&gt; : ... },
 &lt;span class=&quot;code-quote&quot;&gt;&quot;permissions: { &quot;&lt;/span&gt;permissions&quot; : [ ... ] },
 &lt;span class=&quot;code-quote&quot;&gt;&quot;credentials&quot;&lt;/span&gt; : { &lt;span class=&quot;code-quote&quot;&gt;&quot;username&quot;&lt;/span&gt; : ..., &lt;span class=&quot;code-quote&quot;&gt;&quot;password&quot;&lt;/span&gt; : ... },
 &lt;span class=&quot;code-quote&quot;&gt;&quot;saml_credentials&quot;&lt;/span&gt; : { &lt;span class=&quot;code-quote&quot;&gt;&quot;username&quot;&lt;/span&gt; : ..., &lt;span class=&quot;code-quote&quot;&gt;&quot;external_id&quot;&lt;/span&gt; : ... }
}
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;And the module would take care of contacting all responsible submodules and populating them with appropriate data (if it existed).&lt;/p&gt;
</comment>
                                                            <comment id="188427" author="5af5ed55244bc90a106063c7" created="Mon, 26 Jun 2017 07:03:40 +0000"  >&lt;p&gt;&lt;a href=&quot;https://folio-org.atlassian.net/secure/ViewProfile.jspa?accountId=5e1750638dfdd40ec489bf08&quot; class=&quot;user-hover&quot; rel=&quot;5e1750638dfdd40ec489bf08&quot; data-account-id=&quot;5e1750638dfdd40ec489bf08&quot; accountid=&quot;5e1750638dfdd40ec489bf08&quot; rel=&quot;noreferrer&quot;&gt;Katalin Lovagn&#233; Sz&#369;cs&lt;/a&gt;, were you going to update this issue with the notes from our discussion with Istvan and Kurt?  Also, we are now starting Sprint 17.  It would be great if we could close this (assuming it is complete).  Thanks!&lt;/p&gt;</comment>
                                                            <comment id="188430" author="5e1750638dfdd40ec489bf08" created="Mon, 26 Jun 2017 07:56:44 +0000"  >&lt;p&gt;Conclusions of Friday&apos;s meeting:&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;Addresses will be identified by address type for a specific user when updating user data.&lt;/li&gt;
	&lt;li&gt;We should check if users in import should be inserted or updated with a search endpoint (with limited number of users in a call).&lt;/li&gt;
	&lt;li&gt;SSO user identifiers have to be stored in the separate module for SSO authentication.&lt;/li&gt;
	&lt;li&gt;We should generate random passwords when importing user data the first time so that we do not have to deal with importing the passwords of the users.&lt;/li&gt;
&lt;/ul&gt;
</comment>
                                                            <comment id="188432" author="5af5ed55244bc90a106063c7" created="Mon, 26 Jun 2017 08:41:46 +0000"  >&lt;p&gt;Some other key points:&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;SIG has now decided that there will only be one address per type (which is what allows us to use the type as the match point)&lt;/li&gt;
	&lt;li&gt;Address types are library-defined (
    &lt;span class=&quot;jira-issue-macro resolved&quot; data-jira-key=&quot;UIU-79&quot; &gt;
                &lt;a href=&quot;https://folio-org.atlassian.net/browse/UIU-79&quot; class=&quot;jira-issue-macro-key issue-link&quot;  title=&quot;CRUD Address Types&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-79
        &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;
 may go in this sprint (sprint 17))&lt;/li&gt;
	&lt;li&gt;Kurt believes that addresses can be updated in the same call/via same endpoint as the user import update (@jakub, this differs from what you were previously thinking, I believe - we wanted to make sure you had the chance to weigh in)&lt;/li&gt;
	&lt;li&gt;We discussed the SIGs suggestion that &quot;manually created addresses in FOLIO should not be updated from the external source.&quot;  I think we concluded that we wouldn&apos;t explicitly prevent this from happening, but we also wouldn&apos;t expect there to be many issues here.  Suppose there are 4 address types defined for library A.  The import may push in type 1 and 3 for John Doe.  An administrator may add type 2 and 4 via FOLIO UI.  We wouldn&apos;t expect the FOLIO addresses to be overwritten unless the import suddenly pushed data (or a null value) for types 2 and 4.&lt;/li&gt;
&lt;/ul&gt;
</comment>
                                                            <comment id="188435" author="5e16e55ae3b48c0daa0f8727" created="Mon, 26 Jun 2017 08:56:25 +0000"  >&lt;p&gt;I think the requirements are very close to the final list.&lt;/p&gt;

&lt;p&gt;In my opinion the only things left here to decide is if the bulk import will have it&apos;s very own import endpoint or the existing &lt;tt&gt;mod-users&lt;/tt&gt; (or &lt;tt&gt;mod-users-bl&lt;/tt&gt;) insert/update endpoint can be extended/modified to fit these use case scenarios, as well as handling UI operations.&lt;/p&gt;

&lt;p&gt;If &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;&apos;s idea (to use existing insert/update user endpoint) is supported by others, I think we can&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;add tasks necessarily to retrofit the existing endpoint to support import requirements (if there&apos;s any actual need to modify them)&lt;/li&gt;
	&lt;li&gt;add task to create a demo script to serve as a starting point for the SIG in order to create their own institution specific versions (as a side note, Qulto is planning to try this out with it&apos;s own ILS system as an additional validation step)&lt;/li&gt;
&lt;/ul&gt;
</comment>
                                                            <comment id="188436" author="5e16e55ae3b48c0daa0f8727" created="Mon, 26 Jun 2017 09:16:28 +0000"  >&lt;p&gt;I&apos;ve reopened this since it&apos;s made it&apos;s way to &lt;tt&gt;sprint17&lt;/tt&gt;, so it&apos;s still relevant. Also see my previous comment.&lt;/p&gt;</comment>
                                                            <comment id="188437" author="5e1750638dfdd40ec489bf08" created="Mon, 10 Jul 2017 13:24:41 +0000"  >&lt;p&gt;An import script was created. It uses the currently existing endpoints.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10000">
                    <name>Blocks</name>
                                            <outwardlinks description="blocks">
                                        <issuelink>
            <issuekey id="67588">MODUSERS-22</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is blocked by">
                                        <issuelink>
            <issuekey id="35357">MODUSERBL-11</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="67522">MODUSERS-24</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="79880">FOLIO-698</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10003">
                    <name>Relates</name>
                                            <outwardlinks description="relates to">
                                        <issuelink>
            <issuekey id="80205">FOLIO-660</issuekey>
        </issuelink>
                            </outwardlinks>
                                                        </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|hzxp9j:</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>Wed, 14 Jun 2017 17:26:51 +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>