New Data Type - Calendars

[crossan007]

Relates to #3520

IMPORTANT : the calendar if is now to a person on not to a group ( for security reasons ) When a person is deleted the calendar is deleted too : ensure the the integrity of the DB.

So a calendar could be of type calendar or reservation of resources. A calendar could have a parent so we could have a hierarchy like (very important to have a good view of the calendars) :

the calendar type

CREATE TABLE calendar_type (
    `cal_type_id` mediumint(9) unsigned  NOT NULL AUTO_INCREMENT,
    `cal_type_Name` varchar(50) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
    PRIMARY KEY(cal_type_id)
)
ENGINE= InnoDB;

INSERT INTO `calendar_type`(`cal_type_Name`) VALUES ('CALENDAR');
INSERT INTO `calendar_type`(`cal_type_Name`) VALUES ('MATERIAL RESERVATION');
INSERT INTO `calendar_type`(`cal_type_Name`) VALUES ('ROOM RESERVATION');
INSERT INTO `calendar_type`(`cal_type_Name`) VALUES ('VIDEO PROJECTOR RESERVATION');

Calendar Data Type

CREATE TABLE calendar (
    `cal_id` mediumint(9) unsigned  NOT NULL AUTO_INCREMENT,
    `cal_person_ID` mediumint(9) unsigned NOT NULL,
    `cal_parent_ID` mediumint(9) unsigned DEFAULT NULL,
    `cal_Name` varchar(50) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
    `cal_creation` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
    `cal_desc` TEXT COLLATE utf8_unicode_ci,
    `cal_color` VARCHAR(10) NOT NULL DEFAULT '#DC143C', 
    `cal_cal_type_id`  mediumint(9) unsigned NOT NULL,
    PRIMARY KEY(cal_id),
    CONSTRAINT fk_cal_ID
    FOREIGN KEY (cal_person_ID) 
    REFERENCES person_per(per_ID)
    ON DELETE CASCADE,
     CONSTRAINT fk_cal_parent_ID
    FOREIGN KEY (cal_parent_ID) 
    REFERENCES calendar(cal_id)
    ON DELETE SET NULL,
     CONSTRAINT fk_cal_cal_type_ID
    FOREIGN KEY (cal_cal_type_id) 
    REFERENCES calendar_type(cal_type_id)
    ON DELETE CASCADE
)
ENGINE= InnoDB;

[crossan007]

@phili67 I disagree with you - I think that calendars should be associated with groups.

Or at the least - we could have a personal calendar and a group calendar

[crossan007]

The "Calendar Type" should be a DTO, and not SQL tables.

Building this as a DTO could allow us to have different behaviors for various calendar types. I don't believe this "Calendar Type" would be a user configurable option, correct?

[crossan007]

I want to say "no" to a materials reservation calendar type because I would rather have built-in asset tracking at some point (just haven't been focusing on it) - #2345 #2326 #267

The assets would have a reservations table with columns for:

• Check in (DateTime)
• Check out (DateTime)
• Check in by (Person)
• Check out By (Person)
• Condition out (Enumeration)
• Comments (free text)

This would cover your use cases of Video Projector and Materials. These reservations could show up on a calendar, but I don't think fit in the data structure you proposed.

[crossan007]

@phili67 Have you looked at the check-in kiosk feature yet? It's using the event_attend tables already.

It's also using the event<->group relationship to pre-populate the people who can be checked in, and it uses the Nexmo SMS integreation and OpenLP to send SMS and notify parents via the projector:

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 15 days with no activity.