Skip to content

Commit bc9a8fe

Browse files
MartaJuzepczukMartaJuzepczuk
authored
Merge pull request #33 from MartaJuzepczuk/master
Move nomination status from Outgoing to Incoming Mobilities API
2 parents 4b2018b + ae9a823 commit bc9a8fe

File tree

6 files changed

+13
-124
lines changed

6 files changed

+13
-124
lines changed

‎CHANGELOG.md‎

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -5,6 +5,17 @@ This document describes all the changes made to the *Outgoing Mobilities API*
55
document, starting from its first beta draft version.
66

77

8+
0.15.0
9+
------
10+
11+
* Removed two mobility statuses:
12+
13+
- `nomination-verified`,
14+
- `rejected`.
15+
16+
* Removed the `update-statuses-v1` update request type.
17+
18+
819
0.14.0
920
------
1021

‎endpoints/get-response.xsd‎

Lines changed: 0 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -891,25 +891,6 @@
891891
</xs:documentation>
892892
</xs:annotation>
893893
</xs:enumeration>
894-
<xs:enumeration value="nomination-verified">
895-
<xs:annotation>
896-
<xs:documentation>
897-
The nomination was recognized by the receiving HEI as formally correct and
898-
complying with cooperation conditions. Now it's time for settling formalities,
899-
sending student's documents, creating the first Learning Agreement, etc.
900-
901-
In this state, the first LA draft can be editied. Once the LA is signed, the
902-
status changes to "live".
903-
</xs:documentation>
904-
</xs:annotation>
905-
</xs:enumeration>
906-
<xs:enumeration value="rejected">
907-
<xs:annotation>
908-
<xs:documentation>
909-
The nomination has been rejected by the receiving HEI.
910-
</xs:documentation>
911-
</xs:annotation>
912-
</xs:enumeration>
913894
<xs:enumeration value="live">
914895
<xs:annotation>
915896
<xs:documentation>

‎endpoints/update-request-examples/update-statuses-v1.xml‎

Lines changed: 0 additions & 21 deletions
This file was deleted.

‎endpoints/update-request.xsd‎

Lines changed: 0 additions & 80 deletions
Original file line numberDiff line numberDiff line change
@@ -57,7 +57,6 @@
5757
</xs:annotation>
5858
<xs:element ref="approve-components-studied-draft-v1"/>
5959
<xs:element ref="update-components-studied-v1"/>
60-
<xs:element ref="update-statuses-v1"/>
6160
<!--
6261
Note for future XSD designers: When adding new types here, remember to add them
6362
in the manifest-entry.xsd file too.
@@ -200,83 +199,4 @@
200199
</xs:complexType>
201200
</xs:element>
202201

203-
<xs:element name="update-statuses-v1">
204-
<xs:annotation>
205-
<xs:documentation>
206-
This request is usually sent by the receiving HEI when it wants to accept or
207-
reject a group of nominations proposed by the sending HEI. In other words, it
208-
allows to suggest that the status of the mobility should be changed from
209-
"nomination" to either "nomination-verified" or "rejected".
210-
211-
Additionally, receiving HEI MAY also use this API to suggest changing the
212-
status to other values (e.g. notify that the mobility is cancelled), but
213-
servers are not required to support such changes (if a particular change is
214-
not supported for some reason, then the server will describe the fact in its
215-
HTTP 400 response message).
216-
</xs:documentation>
217-
</xs:annotation>
218-
<xs:complexType>
219-
<xs:sequence>
220-
<xs:element name="single-update" minOccurs="1" maxOccurs="unbounded">
221-
<xs:annotation>
222-
<xs:documentation>
223-
This update request may contain multiple "single updates". This is different
224-
than in most of the other update types, which support only a single mobility at
225-
a time.
226-
227-
Servers MUST run this update in a transaction. If something is wrong with one
228-
of the "single updates", then none of the updates should be saved (and the
229-
error response should describe what went wrong).
230-
</xs:documentation>
231-
</xs:annotation>
232-
<xs:complexType>
233-
<xs:sequence>
234-
<xs:element name="omobility-id" type="ewp:AsciiPrintableIdentifier" minOccurs="1" maxOccurs="1">
235-
<xs:annotation>
236-
<xs:documentation>
237-
ID of the mobility being updated.
238-
239-
The sending partner of this mobility MUST match the partner provided in
240-
`sending-hei-id`.
241-
</xs:documentation>
242-
</xs:annotation>
243-
</xs:element>
244-
<xs:element name="new-status" type="omobility:MobilityStatus" minOccurs="1" maxOccurs="1">
245-
<xs:annotation>
246-
<xs:documentation>
247-
Suggested new status for this mobility.
248-
249-
If you want to accept the nomination, then you should send "nomination-verified"
250-
here. If you want to reject it, then send "rejected". You MAY also allow your
251-
users to send other status values, but - if you choose to do so - then you
252-
SHOULD make your users aware, that in many cases such transaction will fail
253-
(because most partners will use this update-type only for accepting and
254-
rejecting nominations).
255-
</xs:documentation>
256-
</xs:annotation>
257-
</xs:element>
258-
<xs:element name="comment" type="ewp:MultilineString" minOccurs="0" maxOccurs="1">
259-
<xs:annotation>
260-
<xs:documentation>
261-
An optional comment. It is RECOMMENDED for comments to be provided only when
262-
necessary (i.e. when nominations are rejected). These comments MUST be visible
263-
only to the IRO members, not the students.
264-
265-
Note, that this API allows for every mobility to have a different comment.
266-
However, it is also okay for the clients to simply "batch copy" a single
267-
comment to all mobilities being rejected.
268-
269-
It is left unspecified how servers should handle these comments - e.g. they may
270-
store them along their mobilities, or they may forward them to specific
271-
persons, etc.
272-
</xs:documentation>
273-
</xs:annotation>
274-
</xs:element>
275-
</xs:sequence>
276-
</xs:complexType>
277-
</xs:element>
278-
</xs:sequence>
279-
</xs:complexType>
280-
</xs:element>
281-
282202
</xs:schema>

‎endpoints/update-response-example.xml‎

Lines changed: 2 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -9,12 +9,11 @@
99
>
1010
<!--
1111
In this particular example, the message is the response to a successful
12-
`update-statuses-v1` update request (in which a couple of students'
13-
nominations have been accepted).
12+
`approve-components-studied-draft-v1` update request.
1413
1514
As noted in XSD, this message is optional. It's perfectly okay for the server
1615
to now supply it. However, if the server supplies it, then the client SHOULD
1716
display it to its user (if possible).
1817
-->
19-
<ewp:success-user-message>Thank you. University of Warsaw's servers had successfully received your approval of 3 nominations.</ewp:success-user-message>
18+
<ewp:success-user-message>Thank you. University of Warsaw's servers had successfully received your approval.</ewp:success-user-message>
2019
</omobilities-update-response>

‎manifest-entry.xsd‎

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -117,7 +117,6 @@
117117
<xs:sequence>
118118
<xs:element name="approve-components-studied-draft-v1" minOccurs="0" maxOccurs="1" type="ewp:Empty"/>
119119
<xs:element name="update-components-studied-v1" minOccurs="0" maxOccurs="1" type="ewp:Empty"/>
120-
<xs:element name="update-statuses-v1" minOccurs="0" maxOccurs="1" type="ewp:Empty"/>
121120
</xs:sequence>
122121
</xs:complexType>
123122
</xs:element>

0 commit comments

Comments
 (0)