Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I got this in my logs
Notice: Trying to get property of non-object in _fullcalendar_update_access()
This happens when the user update an event dragging it, with the only permission to edit his own events.
The function works well on hook_fullcalendar_editable but not as menu item access callback, where the argument passed is not the entity object but just entity id.
Comment | File | Size | Author |
---|---|---|---|
#4 | 1842550-fullcalendar-update-access-4.patch | 1.59 KB | Jorrit |
Comments
Comment #1
Itangalo CreditAttribution: Itangalo commentedI 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.
Comment #2
slcp CreditAttribution: slcp commentedThe '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?
Comment #3
ucaka CreditAttribution: ucaka commentedI 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()
Comment #4
Jorrit CreditAttribution: Jorrit at nCode for DOM Digital Online Media GmbH commentedThe 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 withentity_access()
, adding a dependency on the entity module.