Premising that the Phorge's Calendar supports the Available/Busy picker, unfortunately this feature is completely ignored when importing such events from NextCloud calendar or Google Calendar (or whatever calendar I think).

For example whatever you set in the proprietary Google Calendar in the Available/Busy selector, you are always imported in Phorge as "Busy" (even if "Disponibile" that means "Available"):

This happens also after applying the current improvement in D25363. So you are recognized, but "Busy" instead of "Available":

The problem seems that we do not consider these specifications:

https://www.rfc-editor.org/rfc/rfc5545#section-3.8.2.7

https://icalendar.org/iCalendar-RFC-5545/3-8-2-7-time-transparency.html

https://stackoverflow.com/a/22604346/3451846

Time Transparency is the characteristic of an event that determines whether it appears to consume time on a calendar. Events that consume actual time for the individual or resource associated with the calendar SHOULD be recorded as OPAQUE, allowing them to be detected by free/busy time searches. Other events, which do not take up the individual's (or resource's) time SHOULD be recorded as TRANSPARENT, making them invisible to free/ busy time searches.

In short, here an example of a "Busy" event:

BEGIN:VEVENT
...
SUMMARY:Valerio a Torino
TRANSP:OPAQUE
END:VEVENT

Here an example of "Available" event:

BEGIN:VEVENT
...
SUMMARY:Valerio a Torino
TRANSP:TRANSPARENT
END:VEVENT

Also, you may ask, how in Phorge we persist Busy/Available? In this way:

$ SELECT availability FROM `phabricator_calendar`.`calendar_eventinvitee` GROUP BY availability;
+--------------+
| availability |
+--------------+
| available    |
| away         |
| busy         |
| default      |
+--------------+

Proposed Change

In short we should very probably take care of this import map:

So maybe we can expand this file to take care of this new imported field:

https://we.phorge.it/source/phorge/browse/master/src/applications/calendar/import/PhabricatorCalendarImportEngine.php

So maybe we can expand D25363 - or accept D25363 and add a follow-up patch just for this extra thing.