timekit-io / booking-js Goto Github PK

This can happen if the container that booking.js is inside are hidden/not visible and thus FullCalendar can't properly calculate the width of the widget.

fullCalendar language option is documented here http://fullcalendar.io/docs/text/lang/ but I couldn't get it to work with booking-js.

I've tried both basic booking-js option
{ ... fullCalendar: { lang: "de" }, ... }

and explicit widget init

var widget = new TimekitBooking(); widget.init(config); widget.fullCalendar({ lang: "de" });

Is it possible to use different languages with booking-js at this moment? Thanks.

Can a reminder mail be sent or a webhook called for events?

Can this be customized to collect phone numbers when someone reserves a slot on your calendar?

I have implemented the booking.js plugin and it is beautiful. Nice work. Works really well in PC.

I tested the implementation on mobile and I can't tap the previous and next to look at the following days.

Any ideas or remedies?

Is there any way to use HTTPS via your CDN? I'd like to use the widget but sadly get the following error on our site:

https://cdn.timekit.io/booking-js/v1/booking.min.js Failed to load resource: net::ERR_INSECURE_RESPONSE

😿

Implementation examples: http://bradfrost.com/blog/post/float-label-pattern/
As referenced in #33 by @fragmichdoch

Problem where the a malformed email isn't caught by the frontend form validation and the API returns 422, leaving the form in limbo between loading and error state.

The formatting on the Booking page should also adhere to the localization choice

The CDN links are incorrect on the Readme page.

It currently shows : cdn.timekit.io/bookingjs/1/booking.min.js
It should be : cdn.timekit.io/booking-js/v1/booking.min.js

This occurs in two places.

Integrate the calendar into Facebook pages. Have a look at how Setmore do this.

http://www.setmore.com/features/facebook?OpAdShown

Decided to opt with booking.js as its more open for our APIs!

Maybe this is an issue on Google Calendar's side, but I'm noticing that when I create an event in Google Calendar (thus blocking booking.js from offering slots overlapping with that event), whatever mechanism that prevents booking.js from offering those slots persists even after I delete the event on Google Calendar.

The process for replicating this is:

1. using Google Calendar as the backend, load the booking widget to see availability for a given timeframe (e.g. verify that you see bookable slots from 9am-5pm tomorrow).
2. create an event in Google Calendar conflicting with part of that timeframe (e.g. make an event for tomorrow from 10am-11am).
3. reload the booking widget, verifying that any booking slots that conflict (in the previous example, overlapping with the 10am-11am appointment) are no longer available.
4. delete the event from Google Calendar.
5. reload the booking widget, verifying that the absent slots have not reappeared.

I considered that maybe this was a problem with latency (i.e. Google Calendar is just slow to report that the block has been freed up), but I never saw the timeframe corresponding to the deleted event get freed back up. I'm also reluctant to come to that conclusion since booking.js reflected the unavailability of that timeframe quickly (in other words, it updated very quickly after I created the event in Google Calendar).

Has anyone else encountered this? Is there a good workaround or alternatively some way to prevent it from happening?

If this has all been confusing, I'd be happy to try and walk through the problem more verbosely, even screen-capturing the above steps to illustrate it - I'd just need some time.

The only setting that I could find that would affect this is goToFirstEvent, and whether I set it to true or false, the calendar always displays next week instead of this week. My filters are as follows:

timekitFindTime: {
  future: '1 week',
  "filters": {
    "or": [
      { "specific_day_and_time": {"day": "Monday", "start": 20, "end": 22}},
      { "specific_day_and_time": {"day": "Tuesday", "start": 20, "end": 22}},
      { "specific_day_and_time": {"day": "Wednesday", "start": 20, "end": 22}},
      { "specific_day_and_time": {"day": "Thursday", "start": 20, "end": 22}},
      { "specific_day_and_time": {"day": "Friday", "start": 20, "end": 23}},
      { "specific_day_and_time": {"day": "Saturday", "start": 14, "end": 22}},
      { "specific_day_and_time": {"day": "Sunday", "start": 14, "end": 20}}
    ]
  }
}

Is there some other setting that could be used to define which week shows up by default?

When setting up my widget on booking.timekit.io, it asked me for a list of domain names where I wanted to run the widget. I assumed that the widget would only be able to create calendar events when run on the domain names I specified. However, I was able to successfully book a time slot and see it get created in my calendar, as well as send the confirmation email while running the widget on my development machine at http://octopress.dev (viewing my Octopress site via pow).

That seems unexpected to me, and a security issue, no?

When prefilling and then locking values, undefined is submitted to the submitBookingForm callback

Docs: https://developers.google.com/maps/documentation/javascript/examples/places-autocomplete-addressform

Question: should the API key be customizable or should we create a "mother app" that all widget instances will use? What are the implications?

As referenced in #33 by @fragmichdoch

My google calendar has a lit of recurring events but it seems like they're ignored. Does bookingjs know how to read recurring events or does it only understand unique events?

For some reason whenever I view the calendar on my mobile device, I cannot seem to click on the previous/next date buttons nor can I click the today button to see today's availabilities. However if I visit http://booking.timekit.io/ on my mobile device, those buttons are working fine. Anyone have any idea why its not working on my webpage?

The success message after booking complete could be more clear and expressive, preferably with a message

Maybe this is exposed already, but the documentation leaves me with some questions and maybe someone can clarify.

Some of the people I'm working with would like to describe their business hours as something like 10am-4pm (for example). This means differing from the timezone type of parameter that business_hours typically accepts, but other solutions don't seem to do what I'm looking for. Maybe I'm wrong, so I'll give my understanding of how the other apparent solutions seem to work, and maybe someone can correct me :)

• between_timestamps: will find slots of N duration between timestamp A and timestamp B, but A and B have to be exact dates (so I can't say "Mondays-Fridays 10am-3pm"; I have to say the equivalent of "between Monday, February 1 at 10AM and Monday, February 1 at 3PM").
• specific_time (and specific_day_and_time): will find slots starting at specific_time.start and ending at specific_time.end (but my sense is this could conflict with a parameter like length: '4 hours').

Am I mistaken? The ideal "power user" scenario (from my perspective) would be to allow people to say that they work from A to B and drop the timezone dependence entirely. If someone wants to moonlight from 5pm to 10pm with booking.js, it'd be great if this would let them (without having to do anything weird like change their timezone and block off everything after 10pm with placeholder events or something).

I noticed you guys used karma with jasmine-jquery, I was just wondering if you happened to run into an issue where the fixtures won't load into Chrome because of a content privacy policy or something? Also, how did you get around it?

Hi,

I don't know if it is already possible...
I need a quick booking without sending email confirmation to the client
No email field mandatory

Thanks

I was unsure of what license the code was under so I didn't want to risk looking at it at all.

Please include a LICENSE that indicates if this is a GPL v3, LGPL, Apache license or some other license.

Thanks

I'm getting this error on line:
start: data.start, // Inserted from the chosen timeslot

Here is my code

would be awesome with stripe integration.

Charge for consultations etc.

Problem:

Is there a plan to extend this? For event planning services (wedding and etc), a further view of timeslots in the future is needed. Perhaps extend it to 6 months?

I've notice that if two separate users happens to open up bookingjs calendar page at the same time, user A selects a time slot, and then user B selects the same time slot 2 minutes later, they end up both booking the same slot. Is there any way to prevent the second user from booking the same slot and give them an error message?

Use Case:

I co-own a recording studio, and we receive booking requests for the studio space and/or appointments. However, just because someone requests the booking doesn't mean that they automatically have it reserved. We contact them to know if their request is accepted or declined.

Idea:

When a booking is made with Booking.js, perhaps send it as an invitation from the individual booking the slot, where the owner of the site accepts or declines, notifying the individual and removing the booking if declined.

Do you offer a REST API so we can generate our own "booking widget" using your data?

As suggested in #39:

"This is a similar but seemingly different question, so my apologies if it should be a separate issue - is it reasonable to extend bookings so that appointments are potentially recurring? I can think of a couple of use cases where it would be preferable to set recurring appointments every week or month (compared to manually booking every appointment).

I'm imagining a dropdown option in the booking form field giving options like ["once","weekly","monthly","annually"] or something (I imagine someone will make an argument for including "daily" but maybe we can hash that out or provide some options on the developer's side to expose frequencies)."

As referenced in #33 by @fragmichdoch

pls allow to pre-fill the booking form: something like [my-calendar-url.com]?first_name=John&last_name=Smith&email=[email protected]

i want to define which input fields the booking form should contain. and which of them should be mandatory.

e.g. we would need to enable the booking user to set an address where the appointment should take place.

The use-case is often for support, where users can book a team of e.g. 3 supporters. For a given time, only 1 supporter should be available in order to display the timeslot as bookable.

I just try out BookingJS and it was awesome!

But I noticed a missing feature and I would like to recommend it here.

Create Video Call Event

So, let say I want to request a video call meeting session with the calendar owner, so, I can simply fill-up the form.

Once I click the "BOOK IT" button, it will create an event inside the Google Calendar and automatically add Video Call as the type of the event.

Screenshots:

Hope to see this as one of the available options inside BookingJS config like:

{
  // Required
  email: '',
  apiToken: '',
  calendar: '',

  // Optional
  videoCall: true // false by default
}

Hi team

Have had a dig around, but is there a way to override the default strings in main.js?

For example, we've noticed that a number of users think that booking.js is "broken" when it takes 15-30 seconds to complete the 'booking' action. If we could override the default booking button (for our particular use case, where some customers are less tech savvy) to something like submitText: "Book now (allow 30 seconds)" that would make life a lot easier.

Thanks

I finally found the time to test the widget, and I ran into an issue where the "Book It" button seemed like it wasn't working at all. Then, I noticed that the only way to click it while the credits were present was to very slowly slide the cursor over the top of the button. I tried this in the latest versions of both Chrome and Safari on OS 10.10.5 (Yosemite). In Safari, the credits actually overlap the Book It button, but in Chrome, there is a little space in between them.

The solution to make the button clickable at all times, like it should be, was to disable the credits, which is unfortunate, because I'd like to show my support.