Wish list
- A different calenderview (views: by-day; by-week; by-year) preferably choosable by the end-user (front-end). Setting a default state in this case would be amazing!
- As an extra on the previous point; The possibility to view restrict viewing certain time periods (e.g. in by-week view -> hide weekends || show only tuesdays; in by-month view -> hide holidays; etc.)
- An option to add a comment. (e.g. "closed - reason: anniversary"; "moved days due to holidays"; etc.)
- An option to send an e-mail format per registered e-mail. For every party there should be an option to send different information (e.g. different email for Customer, employee, planner (yes, it can be necessary to coördinate a planning on top of this automated system), administration cooperative, logging storage, etc.)
- An option to annonymize appointment information. Due to the GDPR (the new privacy law), some precautions should be made to minimize the change of a dataleak. Since the general nature of information handled by this plugin isn't that sensitive it is not that big of an issue; Although it would be nice to have tools in place to 'auto-clear' any information after a appointment has been made (the 'appointment-id' should be enough to handle the mechanics internally and externally).
My suggestion would be to set an expiration date for the information (like 1 day after the appointment; 1 hour before the appointment). If storage of information is still important, one can always choose a admin-mail with all the information. Alternatively the next suggestion could be a nice imporvement. - An auto-export tool which exports all the information of a certain period to a cloud service for example. With this it would be possible to export this weeks appointments on every saturday to a (secure) cloudservice.
- Lastly (quite an obvious one); Synchronization with more Agenda types (other than google)
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,
Please login or Register to submit your answer