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...
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...
Comment