Replace gyldigTil with availableSeconds on SigningRequest - #98
Replace gyldigTil with availableSeconds on SigningRequest#98martin-jackson wants to merge 1 commit into
Conversation
b15caec to
0ee7211
Compare
Since the data type is used both before and after the signing request is sent, and the expected behavior is that a request is available for a given duration, it makes more sense to model it as being available for a given amount of time, rather than locking it to a timestamp. Otherwise, to fulfill this expectation we would have to overwrite gyldigTil when sending the request, meaning we would have presented wrong information to the user while the request was still a draft. In terms of capacity it's unnecessary to use long over int, but it's nicer to work with Duration::getSeconds which returns a long.
0ee7211 to
0a21f98
Compare
| @XmlElement(name = "gyldig-til", required = true) | ||
| @Description("When the signing request expires. ISO8601 full DateTime with timezone.") | ||
| @XmlElement(name = "available-seconds", required = true) | ||
| @Description("Number of seconds the signing request stays available for signing after delivery.") |
There was a problem hiding this comment.
Bare lurer, hvis den først settes etter levering, vil det ikke da bli det samme som om vi satt gyldigTil ved levering? 🤔 Eller settes denne med en gang utkast opprettes også?
There was a problem hiding this comment.
Settes med én gang utkastet opprettes (feltet er påkrevd ref. annotasjonene over). At varigheten på oppdraget da er 10 dager (864000 sekunder) er sant både før og setter sending
There was a problem hiding this comment.
Skjønner. Kanskje man skulle endre beskrivelsen til "... after creation." istedet da?
There was a problem hiding this comment.
Det er altså antall sekunder etter levering, ikke opprettelse av utkastet. Vet ikke om du tenkte opprettelse av den sendte meldingen, men tenker at å brukere «levering» er mer presist.
3 participants
Since the data type is used both before and after the signing request is sent, and the expected behavior is that a request is available for a given duration, it makes more sense to model it as being available for a given amount of time, rather than locking it to a timestamp.
Otherwise, to fulfill this expectation we would have to overwrite gyldigTil when sending the request, meaning we would have presented wrong information to the user while the request was still a draft.