Merge pull request #33 from MartaJuzepczuk/master

Move nomination status from Outgoing to Incoming Mobilities API
erasmus-without-paper · Oct 1, 2018 · bc9a8fe · bc9a8fe
2 parents 4b2018b + ae9a823
commit bc9a8fe
Show file tree

Hide file tree

Showing 6 changed files with 13 additions and 124 deletions.
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -5,6 +5,17 @@ This document describes all the changes made to the *Outgoing Mobilities API*
 document, starting from its first beta draft version.
 
 
+0.15.0
+------
+
+* Removed two mobility statuses:
+
+  - `nomination-verified`,
+  - `rejected`.
+
+* Removed the `update-statuses-v1` update request type. 
+
+
 0.14.0
 ------
 

diff --git a/endpoints/get-response.xsd b/endpoints/get-response.xsd
@@ -891,25 +891,6 @@
                     </xs:documentation>
                 </xs:annotation>
             </xs:enumeration>
-            <xs:enumeration value="nomination-verified">
-                <xs:annotation>
-                    <xs:documentation>
-                        The nomination was recognized by the receiving HEI as formally correct and
-                        complying with cooperation conditions. Now it's time for settling formalities,
-                        sending student's documents, creating the first Learning Agreement, etc.
-
-                        In this state, the first LA draft can be editied. Once the LA is signed, the
-                        status changes to "live".
-                    </xs:documentation>
-                </xs:annotation>
-            </xs:enumeration>
-            <xs:enumeration value="rejected">
-                <xs:annotation>
-                    <xs:documentation>
-                        The nomination has been rejected by the receiving HEI.
-                    </xs:documentation>
-                </xs:annotation>
-            </xs:enumeration>
             <xs:enumeration value="live">
                 <xs:annotation>
                     <xs:documentation>

diff --git a/endpoints/update-request-examples/update-statuses-v1.xml b/endpoints/update-request-examples/update-statuses-v1.xml
diff --git a/endpoints/update-request.xsd b/endpoints/update-request.xsd
@@ -57,7 +57,6 @@
                     </xs:annotation>
                     <xs:element ref="approve-components-studied-draft-v1"/>
                     <xs:element ref="update-components-studied-v1"/>
-                    <xs:element ref="update-statuses-v1"/>
                     <!--
                     Note for future XSD designers: When adding new types here, remember to add them
                     in the manifest-entry.xsd file too.
@@ -200,83 +199,4 @@
         </xs:complexType>
     </xs:element>
 
-    <xs:element name="update-statuses-v1">
-        <xs:annotation>
-            <xs:documentation>
-                This request is usually sent by the receiving HEI when it wants to accept or
-                reject a group of nominations proposed by the sending HEI. In other words, it
-                allows to suggest that the status of the mobility should be changed from
-                "nomination" to either "nomination-verified" or "rejected".
-
-                Additionally, receiving HEI MAY also use this API to suggest changing the
-                status to other values (e.g. notify that the mobility is cancelled), but
-                servers are not required to support such changes (if a particular change is
-                not supported for some reason, then the server will describe the fact in its
-                HTTP 400 response message).
-            </xs:documentation>
-        </xs:annotation>
-        <xs:complexType>
-            <xs:sequence>
-                <xs:element name="single-update" minOccurs="1" maxOccurs="unbounded">
-                    <xs:annotation>
-                        <xs:documentation>
-                            This update request may contain multiple "single updates". This is different
-                            than in most of the other update types, which support only a single mobility at
-                            a time.
-
-                            Servers MUST run this update in a transaction. If something is wrong with one
-                            of the "single updates", then none of the updates should be saved (and the
-                            error response should describe what went wrong).
-                        </xs:documentation>
-                    </xs:annotation>
-                    <xs:complexType>
-                        <xs:sequence>
-                            <xs:element name="omobility-id" type="ewp:AsciiPrintableIdentifier" minOccurs="1" maxOccurs="1">
-                                <xs:annotation>
-                                    <xs:documentation>
-                                        ID of the mobility being updated.
-
-                                        The sending partner of this mobility MUST match the partner provided in
-                                        `sending-hei-id`.
-                                    </xs:documentation>
-                                </xs:annotation>
-                            </xs:element>
-                            <xs:element name="new-status" type="omobility:MobilityStatus" minOccurs="1" maxOccurs="1">
-                                <xs:annotation>
-                                    <xs:documentation>
-                                        Suggested new status for this mobility.
-
-                                        If you want to accept the nomination, then you should send "nomination-verified"
-                                        here. If you want to reject it, then send "rejected". You MAY also allow your
-                                        users to send other status values, but - if you choose to do so - then you
-                                        SHOULD make your users aware, that in many cases such transaction will fail
-                                        (because most partners will use this update-type only for accepting and
-                                        rejecting nominations).
-                                    </xs:documentation>
-                                </xs:annotation>
-                            </xs:element>
-                            <xs:element name="comment" type="ewp:MultilineString" minOccurs="0" maxOccurs="1">
-                                <xs:annotation>
-                                    <xs:documentation>
-                                        An optional comment. It is RECOMMENDED for comments to be provided only when
-                                        necessary (i.e. when nominations are rejected). These comments MUST be visible
-                                        only to the IRO members, not the students.
-
-                                        Note, that this API allows for every mobility to have a different comment.
-                                        However, it is also okay for the clients to simply "batch copy" a single
-                                        comment to all mobilities being rejected.
-
-                                        It is left unspecified how servers should handle these comments - e.g. they may
-                                        store them along their mobilities, or they may forward them to specific
-                                        persons, etc.
-                                    </xs:documentation>
-                                </xs:annotation>
-                            </xs:element>
-                        </xs:sequence>
-                    </xs:complexType>
-                </xs:element>
-            </xs:sequence>
-        </xs:complexType>
-    </xs:element>
-
 </xs:schema>
diff --git a/endpoints/update-response-example.xml b/endpoints/update-response-example.xml
@@ -9,12 +9,11 @@
 >
     <!--
     In this particular example, the message is the response to a successful
-    `update-statuses-v1` update request (in which a couple of students'
-    nominations have been accepted).
+    `approve-components-studied-draft-v1` update request.
 
     As noted in XSD, this message is optional. It's perfectly okay for the server
     to now supply it. However, if the server supplies it, then the client SHOULD
     display it to its user (if possible).
     -->
-    <ewp:success-user-message>Thank you. University of Warsaw's servers had successfully received your approval of 3 nominations.</ewp:success-user-message>
+    <ewp:success-user-message>Thank you. University of Warsaw's servers had successfully received your approval.</ewp:success-user-message>
 </omobilities-update-response>
diff --git a/manifest-entry.xsd b/manifest-entry.xsd
@@ -117,7 +117,6 @@
                                 <xs:sequence>
                                     <xs:element name="approve-components-studied-draft-v1" minOccurs="0" maxOccurs="1" type="ewp:Empty"/>
                                     <xs:element name="update-components-studied-v1" minOccurs="0" maxOccurs="1" type="ewp:Empty"/>
-                                    <xs:element name="update-statuses-v1" minOccurs="0" maxOccurs="1" type="ewp:Empty"/>
                                 </xs:sequence>
                             </xs:complexType>
                         </xs:element>