Capture duration of stay for each house member

[jmprathab]

Ability to add the duration of stay for each house member. Users should be able to set From date and To date during which a member stayed in the house.

Endpoints

• GET /houses/{houseId}/rentals - Which returns a list of members and their time range of stay. End time is empty for currently staying member
• POST /houses/{houseId}/rentals - Create a new rental for a house member. Get the start date and end date in request body.

[mslowiak]

1. Should it be a new endpoint?
2. Who would have access to that endpoint?
3. If so, we should have another entity to store all visits in house, right?

[jmprathab]

@mslowiak

• Yes, this should be a new endpoint.
• As of now, we do not have access control for the application. But, in future only community admin should have access to this endpoint(This is something which we can take care of in future)
• It should be a separate entity for each house.

[VinitaNirmal]

@jmprathab Can I pick this task?

[Muhib007dev]

Whats the status now? Is it fixed?Can I try that out. I am a beginner though.

[jmprathab]

@VinitaNirmal Can you please update the status?

[VinitaNirmal]

@jmprathab I have completed the code and raised the PR. I have made the changes according to the reviews done by you too.

[mslowiak]

@VinitaNirmal
We are waiting for you to resolve the conflicts. Could you do that please :)

[mslowiak]

Reopen because of no feedback from developer

[Giluerre]

Hello, I can take this. Can you assign it to me?

[jmprathab]

@Giluerre Sure.

[mslowiak]

@Giluerre
Can you update your status? How it is going?

[Giluerre]

I still need to finish controller and test it.

[mslowiak]

@Giluerre
How it is going?

[Giluerre]

Well... after updating my branch I noticed controller is now uses openAPI generated interface. So I have started migrating + my return type in old method was entity.
My current situation is: I have a problem adding a record to the table. After sending PostRequest from Postman record is added but both my Columns representing time are empty.
EDIT: In the end it was such stupid mistake .... Tomorrow i will create pull request.

[kev711]

@jmprathab Can I take a shot at this ?

[kev711]

@jmprathab A gentle reminder...

[mslowiak]

@kev711
Go ahead :)

[kev711]

Endpoints

• GET /houses/{houseId}/rentals - Which returns a list of members and their time range of stay. End time is empty for currently staying member
• POST /houses/{houseId}/rentals - Create a new rental for a house member. Get the start date and end date in request body.

I have a question regarding this. If the newly created rentals via POST has mandatory start and end time, then shouldn't the GET request send out the same, regardless if the member is currently staying ?

[mslowiak]

@kev711
I had read the description of this task again and yeah, it is a little misleading.

I guess the best option would be to store four types of dates:

• bookingFromDate - mandatory for POST, returned in GET
• bookingToDate - mandatory for POST, returned in GET
• arrivalDate - not used in POST, returned in GET
• departureDate - not used in POST, , returned in GET

What are your thoughts about the solution above? :)

[kev711]

Generally, requirement for capturing any data element should come from a business need. Off the bat, I think together with date, time should also be captured. Maybe capture date and time together as an Unix Epoch time. Do you see any issues with that ?

[kev711]

• Will / Is there another endpoint for adding arrivalDate & departureDate values ? Since they are actuals and will be added at the time of check-in/out.
• Looking at the ER diagram, I think the entity house_member would be a good candidate to store this data, assuming each entry is unique for a stay. Is it ?

[mslowiak]

1. As far as I remember there is no such endpoint because rentals are the new thing there. It should be tackled later after this task will be done.
2. From the house owner's view - you are right. How about the person who is renting a flat/house? In my opinion, we should store those data in a separate place to satisfy this need.

According to your previous question - yes, we should get dates from users as Instant, and store them in the database as data/datetime converted to UTC before.

[kev711]

Hi @mslowiak,
Due to other commitments I won't be able to work on this issue. Kindly un-assign me from this issue. Thank you for all your inputs!

[ErikHalas]

@mslowiak @jmprathab Hey, I'm a university student and we have this class in this semester where the main goal of the class is to contribute code to an open source project. I find this project to be really interesting and would like to contribute. I see no one worked on this issue for quite some time and it seems like something I would like to try to solve. If it's possible please assign me this issue. Thank you.