1
00:00:00,830 --> 00:00:02,780
We got the beginnings of our quest handler put together.

2
00:00:02,790 --> 00:00:06,020
So now we're gonna start to implement the first couple steps in this flow.

3
00:00:06,140 --> 00:00:09,080
We're going to try to find the order that the user is trying to pay for.

4
00:00:09,140 --> 00:00:13,160
We'll make sure that the order belongs to this user and we'll also make sure that the order is not yet

5
00:00:13,160 --> 00:00:13,990
cancelled.

6
00:00:14,010 --> 00:00:17,660
So let's get to it back inside my editor.

7
00:00:17,680 --> 00:00:25,360
I can remove that resource send statement and we will first pull out the token and the order I.D. from

8
00:00:25,360 --> 00:00:27,580
the incoming request body.

9
00:00:27,580 --> 00:00:31,240
We're going to have to refer to these two values right here a couple of times so it makes sense to just

10
00:00:31,240 --> 00:00:33,370
pull them out of the request body right away.

11
00:00:33,980 --> 00:00:38,870
I'm going to use the order model right here to try to find the appropriate order out of our database

12
00:00:39,940 --> 00:00:48,870
there's a council order is a wait order but bind by I.D. and pass in the order I.D. then right away

13
00:00:48,910 --> 00:00:54,110
if we are unable to find the appropriate order we should throw a not found error and say sorry we cannot

14
00:00:54,160 --> 00:00:56,200
find the order you're trying to pay for.

15
00:00:56,350 --> 00:01:01,690
There is no order or throw a new not found error

16
00:01:05,240 --> 00:01:05,690
after that.

17
00:01:05,690 --> 00:01:11,570
Well then check and see if the user who is trying to pay for this thing has the same I.D. as the orders

18
00:01:11,600 --> 00:01:23,190
user I.D. property will say if order a dot user I.D. is not equal to rec not current user dot I.D. And

19
00:01:23,210 --> 00:01:27,340
once again we're getting that little nasty thing from typescript where it's saying sorry we don't know

20
00:01:27,470 --> 00:01:28,810
the current users defined.

21
00:01:28,970 --> 00:01:33,260
We've been over this several times remember require authority has a very stringent check inside of it

22
00:01:33,530 --> 00:01:35,500
to make sure that current user is defined.

23
00:01:35,650 --> 00:01:38,700
So I'm gonna put the exclamation on there to say typescript Don't worry about it.

24
00:01:38,810 --> 00:01:44,180
We already made sure that current user is defined so if those two ideas are not the same we should throw

25
00:01:44,180 --> 00:01:53,940
probably a not authorized error they'll throw a new not authorized error and we should also import that

26
00:01:53,970 --> 00:01:55,630
air from our common module as well.

27
00:01:55,650 --> 00:02:01,710
I did not get that on the initial pass of all these imports so I'll throw in a not authorized air

28
00:02:06,730 --> 00:02:06,930
yet.

29
00:02:07,040 --> 00:02:10,960
And then finally we want to make sure that the order is not yet canceled.

30
00:02:11,060 --> 00:02:26,210
We'll say if order not status is equal to order status not cancelled then let's throw a new bad request

31
00:02:27,590 --> 00:02:32,530
air and we're making use of the order status e number right there which is coming from our common module.

32
00:02:32,570 --> 00:02:35,220
Let's add in import for that at the very top as well.

33
00:02:36,410 --> 00:02:37,100
So up at the top.

34
00:02:37,100 --> 00:02:39,860
From our coming module we'll get our order status

35
00:02:44,850 --> 00:02:46,630
whenever we throw a bad request error.

36
00:02:46,650 --> 00:02:51,470
We also have to provide a reason to say hey here's why you made a bad request so I'll give this the

37
00:02:51,480 --> 00:02:58,380
reason of something like in order to pay for an expired about cancelled order

38
00:03:01,940 --> 00:03:06,830
so if we get past those three checks right there we'll say okay fine you can pay for this thing we'll

39
00:03:06,860 --> 00:03:12,120
try to actually build your credit card to make sure that these three checks at least work we should

40
00:03:12,120 --> 00:03:14,450
do a little quick intermediate test here.

41
00:03:14,520 --> 00:03:18,850
So I'm going to restore that resource sense of success true.

42
00:03:18,870 --> 00:03:26,390
Once again so now in theory we could test this out and try to make a variety of different requests using

43
00:03:26,420 --> 00:03:31,040
postmen we get tried to pay for a order that does not actually exist.

44
00:03:31,130 --> 00:03:35,790
We could tried to sign up as two different users create an order on one and then paper on another.

45
00:03:35,850 --> 00:03:37,910
We could also tried to read an order.

46
00:03:37,910 --> 00:03:38,480
Wait a minute.

47
00:03:38,480 --> 00:03:41,270
But the thing to be expired and then tried to pay for it.

48
00:03:41,480 --> 00:03:46,700
But all those scenarios sound like a lot of tedious work we would have to be using postman quite a bit

49
00:03:46,910 --> 00:03:49,050
just to verify these different cases.

50
00:03:49,050 --> 00:03:53,420
So I think that this is a great scenario where automated testing can make sure that we are doing the

51
00:03:53,420 --> 00:03:56,230
correct thing in all three scenarios.

52
00:03:56,240 --> 00:03:57,100
Let's take a pause right here.

53
00:03:57,110 --> 00:04:00,830
We come back the next video we're gonna start to write out some automated tests to make sure that all

54
00:04:00,830 --> 00:04:02,840
these different cases are handled appropriately.