Easy Appointments
Features
Screenshots
Privacy Policy
Help & Docs
Support forum
Documentation
Hooks and callbacks
How to Connect with System Scheduler – Cron
How to Setup PayPal – Extension plugin
Twilio (SMS) setup tutorial – Extension plugin
FAQ
Demo
Single column – Responsive
Two columns – Responsive
Full Calendar
Responsive single column Right-to-Left layout
Predefined selections – Responsive
Responsive with remaining slots
Standard single column layout
Extension plugin – Smart Button PayPal example
Extension – PayPal example (Legacy Checkout)
j.c._de_vlaming
Questions(8)
Answers(8)
Posts(0)
Comments
As it may differ from implementation to implementation of what should be retained, I would add a choice of which data should be removed and how long after the last appointment.For your app to function properly you need all the data fields, until the appointment date. After that your app doesn't have any use for it anymore, so that should be time-0.So I would imagine a configuration which gives the options to:- never remove data- remove data immediatly after the appointment- at a given time after the appointment (say 1 day; 7 days; 3 weeks etc.)- at a given point per day/week/month/year (every evening at 20:00; every monday at 8:00; every second thirsday of the month at 12:00 etc.)So to give it a visual perspective there are multiple ways to achieve this. Fast solution would be to add a table with every type of selected data (email, appointment time, appointment booking time, custom fields etc.), after each type a column with retention rules (one of the mentioned above).A more fancy solution would be to add a table which contains data-groups. Each group contains the data types, and a retention rule (one of the mentioned above).If you have questions regarding the example described above, feel free to ask(ps. with a table I mean the data-structure, feel free to be creative with the visual stuff 😛 ).
On
Answer for GDPR option
would be a good addition, especially if a day-limit is set
On
move appointment by link: free appointment and choose a new one.
Yep, all is well.Thanks for the fast reply
On
Answer for Unable to remove custom field
*EDIT: there is an clientside error: `405 (Method Not Allowed)`. should say enough I think 😉
On
Answer for Unable to remove custom field
I just succefully removed the field, but apparently I cannot edit any of the fields. Just an error message, no stacktrace (client or serverside).
On
Answer for Unable to remove custom field
I haven't yet, in case you needed a test-case. If you know what the problem is (e.i. don't need a test case) I could finnish up and put the planning-app live.
On
Answer for Unable to remove custom field
If it helps the field settings are the same as the default 'description' field (set when installing the plugin). In the sql-database everything is exactually the same, except for the validation column (which is empty instead of 'NULL'). I do not suspect that it would make a difference, but in any case.
On
Answer for Unable to remove custom field
that would be nice! IMO the ability to customize the layout of the 3 selectionfields (worker, service location), the agenda/planner and the 'custom' fields will improve the usability greatly.
On
Answer for Labels (text) for custom form fields
thanks, an extra entry like #link_cancel_plain# will suffice as well btw. (if thats easier to implement)
On
Answer for Behavior/replacement #link# tags
For testing purposes, nice touch! But that also explains why 😀 thanks for the reaction.
On
Answer for Duplicate booking warning not showing
That would be verry helpfull indeed. If (optionally) old appointments can be cleared as well, this plugin would make the perfect planning app for me (technical wise, skinwise Im curious what additions will come in the near future 😉 ).ps. If you need help with designing, feel free to ask btw.
On
Answer for GDPR option
I set the limit to 1, but still I am able to select a new slot. But maybe I misunderstand something. Does that limit mean you can select at most that number of slots simultaneously? Or does it mean one booker/e-mail adress can make at most 1 appointment per day?If its the first, than it works as expected, but if its the later (which is what I would suspect based on the explanation connected with the field) than something isnt working correctly.
On
Answer for Duplicate booking warning not showing
awesome, thanks for the reactionRegards,
On
Answer for ICalender organiser
it would be nice to have more hooks for these kind of things, as some features can be easily implemented with a custom cron-job
On
Email notification 2 hours before appointment?
I don't think the email/export is the problem (as we can control what will be send already). The main problem is the data retention by EA itself.Basically there are multiple types of data which should be handled in different ways. There is non-personal data (which may be used by everyone).Than there is personal data where the GDPR is in effect.By law there is a set retention-time for each specific personal-data type which we have to comply with. For personal data that usually means that we either need to ask for permanent storage, or have a data-retetion policy in place (which is the main request here!!).To make this feature totally complete we should note that different personal-data requires different retention times. For transaction-related data for example the usual retention-time is 7-10 years (for tax-control etc.), while for an email/phone number or (to make it interesting) medical information, the retention-time should be way shorter.Maybe as an additional reason as to why this is important, personal-data should always be protected by certain standards (high level of encryption, double verification acces etc.). Since I don't think the implementation of these standards are that easy to achieve, the first alternative is to add a retention mechanism (preferably with an auto-export option) so EA doesn't hold the responsibility of data-retention safty.
On
Answer for GDPR option
It seems like the saving-bug is fixed, and i can confirm the issue with ICalender is fixed.Thanks for the help!
On
Answer for iCalander crashes
That's what we found out indeed. Though in order to make things GDPR ready there needs to be extended control over client data.Since the plugin only needs an appointment-id, the time-data and at most a valid email addres to make all the synchronization/logic work, there should be an option to control the retention of the remaining data (e.g. name, phone number, any custom fields etc.).I noticed that Wordpress has published an API for personal data control, maybe it is an option to hook into that system? Otherwise, the instalment of a cron-job, which removes additional/extra data would suffice the requirements IMO. (setting it to 5 min. vs. every weekend is a personal option in that case).I would love to hear your thoughts about this!Regards,
On
Answer for GDPR option
What I was thinking, is it possible to attach the file with the e-mail test tool? That way maybe we can see something in the error log display underneath the test info?
On
Answer for iCalander crashes
That'll do as well indeed :DAny information about the data-retetion control?
On
Answer for GDPR option
It seems like this is a bug of the forum itself? I used a Base64 image to embed it in the post (as the buildin image takes a hosted image rather than an uploaded).Basically when entering such an image you put something like:Sadly this forum trims the 'data:' prefix from the image source, making it unrecognizable for the webbrowser. (e.g. it would make it look like:)If you add the prefix yourself it will show the image again (though it will require you to go into developer/editor mode).
On
Answer for GDPR option
Hey,First of all thanks for the amazingly fast reaction. Im looking foreward to the different view possibilities!For the second point; I can imagine it being a complicated task, although it can be implemented per entity? (e.i. either location, service or worker not available for a period of time). This way you can simply invalidate the whole connection/link, which should show the desired result (Assuming the algorithm currently in place will take over)?I am not sure how its programmed in the backend (I have currently way too less time to dig through all the code). But if I could help in any way, I would happely do so.Anyway, any comments about the other (last) 5 points in terms of feasibility?Regards,
On
Answer for Wish list
Crop