_fullcalendar_update_access() expects entity (object), receives entity id (string) as menu access callback

I think I have this same error. A user with permission to edit own content can drag-and-drop in the calendar, but the item isn't saved. (Rather, the drag-and-drop is treated as a click, and the user is redirected to the item page.)

I'm using this on nodes, and the log says message fullcalendar/ajax/update/drop/438 (where 438 is the NID).

I tried adding this to _fullcalendar_update_access($entity), but with no result:
return entity_access('update', $entity->entity_type, $entity);

Maybe the bug is somewhere else, and the _fullcalendar_update_access($entity) is actually returning the proper access.

The 'fullcalendar/ajax/update/%/%' menu callback uses this function as an access callback but passes it a numerical id instead of an entity object.

Additionally the 'bundle' property is not present on all entities, nodes for example - they use $entity->type. The fullcalendar module prepares entity objects with a 'bundle' property when this function is called elsewhere.

I think we should be using node_load/user_load here to load the object when required and check content (node) and user permissions for now.

Ideally we could call entity_load/entity_access and be done with it but without entity being a dependency of fullcalendar this wont work. Or should we say that entity is the new views and sites that do not have it are the edge case?

I suppose that a lot of refactoring should be done here so we can know what entity is being updated.
For now a workaround is to implement a custom module to alter the menu and populate an entity object in the access callback.
It wouldn't work on other entities though.
Also you can use the api function hook_fullcalendar_editable()

/**
 * Implements hook_menu_alter().
 */
function MY_MODULE_menu_alter(&$items) {
    $items['fullcalendar/ajax/update/%/%']['access callback'] = '_MY_MODULE_update_access';
}

function _MY_MODULE_update_access($entity_id) {
    //For now load the node entity :( and pass it to _fullcalendar_update_access
    $entity = entity_load_single('node', $entity_id);
    if (is_object($entity)) {
        $entity->bundle = $entity->type;
    }
    return _fullcalendar_update_access($entity);
}

The attached patch fixes the problem by reading entity_type from $_POST (as also done in the page callback fullcalendar_update()). I also replaced the node-specific access check with entity_access(), adding a dependency on the entity module.

I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module as "Closed (outdated)". That includes any Drupal 7-compatible versions because no active maintainer is supporting them.

If this issue is still relevant for version 3.x of FullCalendar, then feel free to re-open it and update the issue version number.