Endpoint for booking an amenity

[jmprathab]

⚠️ Is your feature request related to a problem? Please describe

• Endpoint for booking an amenity

💡 Describe the solution you'd like

• POST /amenities/{amenityId}/bookings
• Update postman collection

Task Relationship

Subtask of: #94

[zhupanovdm]

@jmprathab Hello, I'm new in open source, can I take this task?

[jmprathab]

@zhupanovdm Sure. Request you to comment on your approach before implementing.

[mslowiak]

@zhupanovdm
Any update from you?

[zhupanovdm]

Hi. Sorry for silence. There was a lack of spare time. But now I'm in.

[mslowiak]

@zhupanovdm How it is going?

[mslowiak]

It has been 9 days since last update, task is still up for grabs :)

[tomsajuk]

Shall I take this up?

[tomsajuk]

Hi @jmprathab had some queries regarding the issue. Posting it below:

1. Should a user be able to book an amenity for another user? (neighbours maybe)
2. Any restrictions on the number of bookings and people at a particular time-slot? (There would be rush during weekends)
3. Can assume that the user can only book an amenity available in his community? (Would be throwing error if outside the community, so what error should I throw?)
4. Whats the purpose of the 'price' attribute in the Amenity domain? Should the user be paying at the time of booking or its a membership fee?

If you could answer these queries would help a lot in the implementation. :) If you add your thinking that would also be good.

[jmprathab]

Hi @jmprathab had some queries regarding the issue. Posting it below:

1. Should a user be able to book an amenity for another user? (neighbours maybe)
2. Any restrictions on the number of bookings and people at a particular time-slot? (There would be rush during weekends)
3. Can assume that the user can only book an amenity available in his community? (Would be throwing error if outside the community, so what error should I throw?)
4. Whats the purpose of the 'price' attribute in the Amenity domain? Should the user be paying at the time of booking or its a membership fee?

If you could answer these queries would help a lot in the implementation. :) If you add your thinking that would also be good.

Great thoughts BTW.

1. Let's not do this.
2. Yes. Booking overlap should be restricted.
3. HTTP 403 can be returned in case. Note: Implementation has to use AuthorizationFilter rather than having the logic in the controller. master has similar implementations already.
4. User is not expected to pay for the amenity while booking. The idea is, CommunityAdmin might be able to generate a payment for a particular user for using an amenity.

[douglas-oliveira-talkdesk]

@tomsajuk Are you working into this task? If not, can I please get it?
Thanks 👍

[tomsajuk]

@douglas-oliveira-talkdesk sure you can go ahead. Not getting time to work on this.
@jmprathab assign it to him please

[DDmit04]

can I take this?

[mslowiak]

@DDmit04 yes ;)

[jfjara]

Hello, Could I take this? Regards

[bayotheman]

Hi @mslowiak @jmprathab could I take this task?

[bayotheman]

Hi @mslowiak @jmprathab just another reminder, could I take this task?

[alexniko44]

is this task up for grabs?

[aman-junaid]

Hi @mslowiak, @jmprathab,

Is anyone working on this?? or its up for Grabs?

[cjhier]

Hi @mslowiak, @jmprathab,

Is this up for grabs? I'd like to look into it.