# Bookie - booking stuff with Holochain Node middleware **(Depreciated)** - Node email/password auth - one private key to auth with HC backend - Node middleware checks that the email is correct and then relays the calls to the holochain conductor -> all holochain zome calls receive as parameter the email of the agent making the request Website module - form to request resource booking un-authenticated Roles: - Customer: unathenticated user making a request to book a slot - Provider: provides the resource, and manages the requests for that resource - Admin: register new providers User stories: - As an administrator, I should be able to add new providers by email - As an administrator, I should be to see all the events for all the resource - As a provider, I should be able to add new resources - As a provider, I should be able to see the requests to book a given resource (calendar) - As a provider, I should be able to accept or reject requests to book resources - As a provider, I should be able to see what already accepted bookings a resource has - As a customer, I should be able to see the list of resources - As a customer, I should be able to see the free slot that a resource has - As a customer, I should be able to request to book resources for free slots **Resource** definitions: - Name - timeslot - image - description - (optional) address **Profile** definitions: - Avatar - Full name - Organisation name - Email - Phone number ## Membranes One DNA per space, read available to anyone looking a website looking to make a booking. In a case like a village where it is internal resources being booked. A person needs to be invited into the DNA in order to have the resources visible. ## Considerations on integrating payment for bookings When a booking has been accepted by the owner of a resource (a room, a consultancy slot, a bike, whatever) there may or may not be an economic cost related to that booking. This might need to be a part of the booking entry, or it would be a seperate payable entry. This entry should be able to be updated, either programatically if someone would pay with a connected system (internal credit, HoloFuel, etc.) or manually by the reciver if someone pays by mobile pay, cash or whatever. An internal credit system is probably best in cases where it is an internal DNA (the case within a village) while accepting outside payments and checking the entries off manually would be needed for outside customers booking event spaces. - Invoicing -> REA based mapping ## Zomes - MembraneRoles: DNA wide roles - EntryRoles: roles per resource - Profiles - ResourceBookings: validation -> only if agent is "manager" of resource - Calendar element segmented by resource - Resources: for now one zome per type of resource - Meeting rooms: start with this - Production of vegetables... - CalendarEvents - Calendar element with different calendar management - Nice to have, depending on energy - Unauthenticated view of events - Even eventbrite┬┐? (right now people are using Facebook) ## tasks: Guillem: Viktor: get help from David to start making the static asset site. ## Github https://github.com/zaunders/Bookie