backpack/calendar-operation - bug/inconsistency trying to populate event extendedProps using getCalendarFieldsMap()

[tomsb]

extendedProps typically contains additional event data, but it does not always include all the fields defined in getCalendarFieldsMap(). For example, I have the following fields in getCalendarFieldsMap():

'module_number' => 'module_number',
'pk' => 'pk',

The module_number field appeared in event.extendedProps (when I clicked on the event), but pk did not. I am unsure why pk was missing initially. However, after I explicitly added extendedProps in the eventData, the pk field appeared in extendedProps.

This behavior is strange. I did not investigate further to understand why this inconsistency occurred.

File: calendar_view.blade.php (From line 269)

 let eventData = {
      id: entry[fieldMap.id],
      title: entry[fieldMap.title],
      start: entry[fieldMap.start],
      end: entry[fieldMap.end],
      color: entry[fieldMap.background_color],
      textColor: entry[fieldMap.text_color],
      allDay: !entry[fieldMap.end],
      editable,
      buttons: entry.buttons,
      ...extra,
+      extendedProps: {
+          ...extra,
+      },
  };

[backpack-ai-bot[bot]]

🚨 Bot is not sure about this answer. Please verify. 🚨

Based on the information provided in the knowledge sources, I don't have enough specific details to fully explain the inconsistency you're experiencing with the extendedProps in the backpack/calendar-operation. However, I can provide some insights and suggestions based on the available information.

The getCalendarFieldsMap() method is used to map your model fields to the calendar fields. As shown in the Calendar Operation Installation guide, you can map additional fields beyond the default ones:

protected function getCalendarFieldsMap(): array
{
    return [
        'title' => 'title',
        'start' => 'start',
        'end' => 'end',
        'background_color' => 'background_color',
        'text_color' => 'text_color',
        'all_day' => 'all_day',
        // You can add additional fields here
    ];
}

The inconsistency you're experiencing with module_number appearing in extendedProps but pk not appearing is not explicitly addressed in the provided documentation.

Your solution of explicitly adding extendedProps in the eventData is a valid workaround:

let eventData = {
    // ... other properties ...
    extendedProps: {
        ...extra,
    },
};

This ensures that all additional properties are included in the extendedProps object.

To further investigate and potentially resolve this issue, you could:

1. Check if there's any difference in how module_number and pk are defined in your model or how they're being retrieved from the database.
2. Verify that both fields are actually present in the entry object before they're assigned to eventData.
3. Consider updating to the latest version of the calendar-operation package, as there have been several updates that might address this issue. The latest changelog shows version 1.0.9 as the most recent release.

If the problem persists after trying these steps, I recommend opening a discussion in the Backpack community forum as suggested in the Support section of the documentation. The Backpack team or community members might be able to provide more specific guidance on this issue.

ℹ️ Please note our AI Bot does not reply to follow-ups, this will be the only AI answer in this thread. If the AI helped you find the answer, please mark it as answered or write details below so it can learn. Then close the conversation. If not, please give more information for when a human reads this. ℹ️

Relevant sources:

Github Issue (closed): [Bug] Issues on "backpack/calendar-operation"
Github Issue (closed): Calendar operation doesn't support getters
Calendar Operation|Installation
Calendar Operation|Changelog
Github Issue (closed): CalendarOperation drag drop updates wrong time.
Calendar Operation|Calendar Operation
backpack/calander - Start and End Date not showing datetime.
Github Issue (closed): [Bug] Issue related backpack/calendar-operation , one hour behind in database upon visual time slot selection

[jcastroa87]

Hello @tomsb

Can you share with me the migration and model to replicate the problem on my side.

Can you please share versions too:

php artisan backpack:version

Thanks.

Cheers.

[tomsb]

Suddenly, I can no longer reproduce this behaviour. I performed some updates and can't easily revert back.

It seems I misunderstood how everything fits together.

Here's what I wanted to achieve: adding a custom value to the event.extendedProps. The steps I followed:

1. Use getCalendarEntries as traitGetCalendarEntries (alias the original trait method)
2. Add custom field like this:

public function getCalendarEntries(Request $request): Collection
    {
        $entries = $this->traitGetCalendarEntries($request);
        $entries = $entries->map(function ($entry) {
            $entry['foo'] = 'bar';

However, this didn't work as expected. It turns out that I also need to add the same custom field in the getCalendarFieldsMap() method for it to appear in event.extendedProps (this becomes clear by looking at calendar_view.blade.php)

This detail might be worth adding to the calendar documentation. Should we close this issue?