[ANGULAR] Cannot read property 'id' of undefined on Add Event

[alexc-inforit]

Hey, we've encountered a strange problem when adding an Event in the Bryntum Scheduler.
Before describing more the issue we want to mention that we've encountered it when migrating from 3.1.3 to 4.0.3 version of the Scheduler.
We are aware of the breaking changes and we've checked the official Changelog page to mitigate the issues that can appear from migration.

The steps we are doing to reproduce the issue are:

1. We go on the Scheduler and select a period by drag and drop
   
2. Then fill all the info in the Event Editor
   
3. Press Save

Now we get an error in the scheduler.module.js saying that "Cannot read property 'id' of undefined".

It is something strange with the following line:
const [assignmentRecord] = eventStore.assignEventToResource(eventRecord, resourceRecords);

It returns somehow 'undefined' and crashes on
DomSync.addChild(scheduler.foregroundCanvas, element, assignmentRecord.id);

We've noticed that also on v 3.1.3 it returns 'undefined' but the value was not used.

[mats]

Doesn't ring a bell - any chance you can boil this down to a minimal test case for us? Then we can fix it quickly.

[alexc-inforit]

We’ve made some research and here are what we’ve found might be a possible bug:
In the first place, we are using the EventEditor with a single assignment configuration as mentioned in the docs at point 3: https://www.bryntum.com/docs/scheduler/#guides/upgrades/4.0.0.md

1. We are going and create a single assignment event
2. When the ‘Save’ button is pressed it will end calling the ‘finalizeEventSave’ method
3. On line 128392 it will call the "evenStore.assignEventToResource" method which then pass the its arguments to “assignmentStore.assignEventToResource”
   
4. Here it seems to be a problem with single assignments as the “assignEventToResource” method always returns an empty array for this kind of assignments(line 99273)
   
5. Then when it will return back to the “finalizeEventSave” method we’ll always have the assignmentRecord constant set to undefined causing Bryntum to break on line 128402
   

[pmiklashevich]

We could not reproduce this issue. To assist you with your question, please provide more details including a runnable test case (as described in our support guidelines).

To get the fastest possible support, provide a simple test case based on our standard examples.

[alexc-inforit]

While we were trying to put together a runnable example with the issue we found its cause.
It turns out to be because we were overwriting the name of the resource field in the editorConfig.

public eventEditFeature?: any = {
        editorConfig: {
            items: {
                resourceField: {
                    name: "resourceId",
                },
            },
        },
    };

When this is done the event save no longer works correctly.

[pmiklashevich]

resourceField.name is kind of internal property and it equals to "resource". The internal event editor implementation relies on it. What is the reason to change it?

[wizard]

I ran into the same issue. Wouldn't it make more sense, that you kinda protect this attribute or at least state this in your docs?

[alex.l]

Hi wizard,

We do not prevent override of our build-in logic/forms/fields, but in case a user will override it partly, like change the name of build-in field, or name of the form and leave all default handlers that rely on it - it may be buggy. It's hard to predict what exactly and how a user will make extensions/overrides.

We are open to any ideas that can make our products easier to use.

All the best,
Alex

[pmiklashevich]

The issue should be fixed now. Please download 4.1.0-beta-3 to confirm.