Issue parsing "lesson"

[Sobuno]

<a href='javascript: void' onclick="javascript: LectioContextMenu.ShowContextMenu(event);" class="s2skemabrik s2bgbox s2bgboxeksamen s2withlink lec-context-menu-instance" style="position:absolute; top:0em; left:0.55em;height:38.18em;width:6.73em;word-wrap:break-word;"
    data-additionalInfo="----REDACTED---
xx/x-xxxx xx:xx til xx:xx
Lærer: x

Note:
x">
    <div class='s2skemabrikInnerContainer'><span class='s2skemabrikIcons'><img alt="" class="picwidth14" src="/lectio/img/note.auto" /></span>
        <div class="s2timeline">xx:xx-xx:xx</div>
        <div class="s2skemabrikcontent">
            <span style='word-wrap:break-word;'>----REDACTED---</span><br />
            <span data-lectioContextCard='----REDACTED---'>x</span></div>
    </div>
</a>
<div class='lec-context-menu'>
    <ul>
        <li><a href='---Actual link 1 with ID 1----'>---REDACTED---</a></li>
        <li><a href='---Actual link 2 with ID 2----'>---REDACTED---</a></li>
    </ul>
</div>

LecToCal fails when it encounters the above entry in my wife's calendar (Redacted a lot of information). Notice that href is pointing to javascript: void, which means LecToCall will throw an error about not finding an ID. When you click on the entry in Lectio, it gives you a popup/context menu with the two links mentioned in the bottom of the code.

Lectio's own handling of finding the proper context menu is seen here:

        var etarget = $(e.target);
        var target = etarget.closest('.lec-context-menu-instance');
        if (target == null || target.length === 0) {
            target = etarget.parent('.lec-context-menu-instance'); //fallback to parent
        }
        if (target && target.length > 0) {
            var content = LectioContextMenu.GetContextMenuContent(target);

and GetContextMenuContent looks like this

        if (instance && instance.length > 0) {
            var content = instance.hasClass('.lec-context-menu') ? instance : null;
            if (content && content.length > 0) {
                return content;
            }
            content = instance.next('.lec-context-menu');
            if (content && content.length > 0) {
                return content;
            }
            content = instance.children('.lec-context-menu');
            if (content && content.length > 0) {
                return content;
            }
        }
        return null;
    };

In other words, it first checks if itself is the context-menu, then if the next sibling is (which is the case in my example) and finally if the children are.

I am satisfied with the information in the original entry; my problem is how to generate an ID I can reference again later if something changes as what we would usually get the ID from is replaced by javascript: void. LecToCal's structure doesn't really lean itself to looking at the next sibling to obtain an ID. Also note that the two links in the context menu have different IDs, meaning it actually does not link back to the "main" lesson.

[Sobuno]

Currently I have modified my local branch to ignore the entry, but that is not an ideal solution.

[Hanse00]

So if I'm understanding correctly, the problem here is that the following line, assumes that an event containing a link, must also contain an ID, is that correct?

LecToCal/lectocal/lectio.py

Line 202 in a4bdf4e

id = _get_id_from_link(link)

Searching siblings for the context does seem like it would involve a significant amount of overhead.

It might be worthwhile to reconsider the entire concept of how ID's are determined - Especially as some events don't contain any obvious ID information. The current method for generating ID's for these events is prone to breaking if any details about the event change.

[Sobuno]

Currently I think we are basing all event IDs on the IDs obtained from the href attribute of the a tag, yes. I don't necessarily think that ID will change if details change, but it is a problem with situations like this.

[Hanse00]

It looks like we currently apply one of two strategies to generate an ID.

An event that doesn't currently have an ID, can have one generated by the following method:

LecToCal/lectocal/lesson.py

Line 72 in a4bdf4e

def _gen_id(self):

That method concatenates the various event details, and hashes them. Meaning any event modification, would result in a different ID.

The other method gets the absid, ProeveholdId, or outboundCensorID part of the href tag, inside the s2skemabrik element.

The problem seems to be coming up with a stable ID for events that don't have one built in.
If we want to be able to update the calendar event properly on event changes, we need some way of knowing that the new event is an update of an old event, and not a totally new event.

I don't see an obvious solution however, to coming up with such an ID.
Presumably it must exist internally in Lectio, but it doesn't seem to be exposed in a way we can work with.

IDs are currently needed for uniquely identifying an event in Google Calendar, so that the update loop knows which events have changed. However Calendar is able to generate IDs itself.

Perhaps the real solution is to not rely on these IDs for comparison, but rather compare the objects themselves? We could make a "near equal" comparison, considering events where only one field is different between the two, to be the same event which has been updated. - This would build on an assumption that only one thing changes about an event at any given time, something I'm not sure is correct.

It's something that seems worth investigating more closely, to build a more stable certainty what does and does not need to be updated.

[Hanse00]

I've had a while to think about this, and I think the following is the best steps forward:

IDs will be generated as a hash of the event details.
This means that we won't be updating events, but replacing them, as changed details mean a new ID, so the calendar won't have any way of knowing that it's the same event with a change.

This means slightly more overhead, with removing and adding events, rather than updating them, but it means that we can always reliably generate an ID, and that (Unless you have two identical lectio events) they will never clash.

[Hanse00]

Looks like I previously accounted for exactly this, by allowing an event to create an ID in exactly this manner, if one isn't supplied beforehand. So it turns out the only problem here is that I forcibly throw an exception if a link doesn't contain an ID, rather than moving on.

[Hanse00]

I've pushed a branch including the fix to: https://github.com/Hanse00/LecToCal/tree/feature-automatic-ids @Sobuno would you be able to test if this works, since you seem to have access to one of this type of events?

If so, I will go ahead and push the update.