Some extensions and modifications
Collapse
X
-
Hi emillod, MaxDau ,
i am not here for proposal my skill, i don't have skill .. but not really understand your request and it's just for share my experiment, 100 entity it's crazy for me.. maybe you say 100 records. (of course, i don't know your business)
in the past, i have proposal something like to my boss :
out-of-box espoCrm.
Account -> many2many -> Contact.
Avability to have "calendar" for Account and of course contact related to Account.
So Account->calendar = is like teams Calendar and each contact have private calendar it's like ACL out-of-box espoCrm.
And of course, portal users have access with ACL to Account->calendar or Personal->calendar.
This was for us a extension i will need, in the past, because now we stop ours business.
But i think this kind of extention can find many project
Best Regards -
CalDav is not supported by the third-party providers. The CRM is to become a central syncronisation point for calendars. The only interface that is identical for all platforms would be ical.
At the moment we have a many-to-many synchronisation for each calendar of an entity. This means that every calendar has to be registered with every other calendar.
With 5 calendars per entity, 4 calendars each query a different calendar. So calendars 2 - 5 query calendar 1, calendars 1,3-5 query calendar 2 and so on.
The target is that the CRM retrieves all calendars, combines events and all external calendars only have to synchronise the entity's calendar from the CRM. So for calendar 1 I only have to register the entity's CRM calendar and not 4 others.
Retrieving the calendars and evaluating the entries is very easy. I have tested this today on the side and have a few ready-made classes that already analyse 2 calendars.
Contacts, File or other are not available. The calendar only shows whether something is reserved/blocked, which ID the reservation has and perhaps an ID or a link to call up details in the browser. (Blocked has no ID, because no reservation, just blocked)
Code:BEGIN:VCALENDAR VERSION:2.0 CALSCALE:GREGORIAN PRODID:None BEGIN:VEVENT UID:8f760461-ed8d-4a9f-89ce-25093b3c28ff DTSTAMP:20221208T050122Z DTSTART;VALUE=DATE:20200718 DTEND;VALUE=DATE:20200725 SUMMARY:Belegt - Sandra END:VEVENT BEGIN:VEVENT UID:70fe17d9-5e25-427c-a122-148a3a147834 DTSTAMP:20221208T050122Z DTSTART;VALUE=DATE:20230721 DTEND;VALUE=DATE:20230723 SUMMARY:Geblockt END:VEVENT END:VCALENDAR
There is a simple reason for all this. We expect over 100 entities by the end of 2023. When we add, change or remove a third party, we have to change the calendar every time at 100 entities x 4-5 third parties. This is a workload that can easily be automated away.Leave a comment:
-
We have already working extension which allow to:
1. Sync contacts through CardDAV
2. Sync calendars through CalDAV
3. Manage documents e.g. as map drive, through WebDAV
It'll be available for sale in this or next monthLeave a comment:
-
You might want to look into CalDAV as that is more web standard for calendar.Leave a comment:
-
Some extensions and modifications
Hello
I need an extension to use EspoCRM as a central calendar.
- One calendar per entity
- Import from ical per entity
- Export of ical per entity / total
- Optional password protection / link generation with hash
- Filter in existing calendar by entity, status, ...
Optional tasks
- Hooks for calendar actions (event: new, changed, deleted) from ical
- Integration in API
Details:
An entity has different events. The calendar should be retrievable via GET ical.domain.tld/$hash(random)/$hash(id)/$filter[].
Extra settings in the entity, if no filter is specified, which events (type, status) are output.
(Several) external calendars of the entity should be retrieved at regular intervals. New events should be created as events. Change events that have been changed, but note the change. Deleted events should be set to a specific status and marked as deleted (no longer delivered in ical and displayed in the internal calendar).
In the internal calendar, it must be possible to filter events not only by entity type (as is currently the case) but also by individual entities of a contact or an entity.
There are other adjustments, but they do not have a high priority at the moment and can be done next year.
(if this would not already be possible)
- Making calendars available via API
- Possibility to execute hooks for ical imports.
- Better (faster) filters for emails (by email account)
- Simple calendar view in the portal (without interactions, only display of events and free days)
- Adjustments to the portal such as form wizards
and more...
Tags: None
Leave a comment: