While the second one would be correct, the first one is not - I haven't looked at the code for this, but the CMS appears to simply take the last two path segments of the data path when generating the lock path; this assumption breaks down for one-off items, as those only have a single path segment identifying the item.
The (possible) consequences:
Given that Webhook uses Firebase, there's no formal schema - the buggy path generation has now become part of the informal scheme, and other tools interacting with the Webhook database need to reimplement the bug.
If a content type named data were to ever exist, and it were to contain an item with a key equalling the name of a one-off content type, this would create a lock name collision - and potentially break editing as a result.
Given the following two fictitious data paths in Firebase:
... where
aboutis a one-off content type, andpostsis a 'regular' content type, the lock paths would look something like this:While the second one would be correct, the first one is not - I haven't looked at the code for this, but the CMS appears to simply take the last two path segments of the data path when generating the lock path; this assumption breaks down for one-off items, as those only have a single path segment identifying the item.
The (possible) consequences:
datawere to ever exist, and it were to contain an item with a key equalling the name of a one-off content type, this would create a lock name collision - and potentially break editing as a result.