Description

This PR fixes a bug where extending a guest invitation that is set to "Never expire" results in the expiration date being reset to the Unix Epoch (Feb 1, 1970), causing the invitation to expire immediately.

The Problem

When a guest invitation is created with the "does not expire" option, its expires field is stored as null (or 0).
When the "Extend" action is triggered:

1. The backend (DBObject::extendObjectExpiryDate) adds the extension duration (e.g., 30 days) to the current expires value.
2. Since expires is 0/null, the calculation becomes 0 + duration.
3. The result is a timestamp corresponding to early 1970.

Root cause: The system allows extending a date that doesn't exist (infinite), and the math operation treats "infinite" as zero.

The Solution

I have implemented a safeguard in both the frontend and backend to prevent this action for non-expiring guests.

Frontend (guests_table.php & guests_table.js):

• Added a data-does-not-expire attribute to the guest rows.
• The Javascript now checks this attribute. If the guest does not expire, the "Extend" (clock icon) button is hidden.

Backend (RestEndpointGuest.class.php):

• Added a check in the put method.
• If a request tries to extend a guest that has does_not_expire set to true, the server throws a RestBadParameterException. This prevents API calls (intentional or accidental) from corrupting the date.

Files Modified

• templates/guests_table.php - Expose does_not_expire status to the DOM.
• www/js/guests_table.js - Hide the extend button if the guest does not expire.
• classes/rest/endpoints/RestEndpointGuest.class.php - Block extension requests for non-expiring guests.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature
• Enhancement