Calendars on multlingual sites expose some problems and errors.
By design a calendar is shared between nodes that are a translation of each other. This is done by using the nid of the base node as id for the calendar. (i.e.: if a node has the field tnid filled with a value different from its field nid, the tnid is used as calendar id.) this gives rise to a number of questions/problems/errors:
Access:
May a user edit a calendar that is linked to a node he does not own, if he owns a node that is a translation of this node?
Cache:
Is, on saving a calendar, the cache cleared for nodes that are translations of the node the calendar is linked to?
Settings:
If settings can be overridden per node, should each translation be allowed to have its own settings?
View/edit:
Should nid's used in html element id's and links (to view/edit a calendar) be taken from the base node or from the translation node? And do these view/edit pages show the correct calendar?
Access:
Yes, with the "edit own availability calendars". Thus a calendar linked to the base node of a translation is considered an own calendar. This gives just a bit more options to handle access.
Cache:
Should be cleared.
Settings:
The defaultstatus and splitday setting are settings that cannot be different for different nodes that are linked to the same calendar. (The same could be said for the combination of weeknotes enabled and startofweek setting.) So, we cannot allow different settings for different translations.
View/edit:
The module will use the nid of the node being shown/edited. Showing editing the correct calendar will be taken care of internally. This allows to keep html element id's unique in listings of nodes that may contain translations of each other.
Access:
This currently works as decided.
Cache:
Currently only the cache is cleared for the base node (the node the calendar is linked to). This is an error.
Settings:
Currently, the calendar settings are stored with the node being edited, not the (base) node the calendar is linked to. This is an error.
View/edit:
Within themed output the calendar id is used, most js script uses the node id of the translation. This is an error, leading to non-functional javascript.
Comments
Comment #1
fietserwinAnd 2 more problems:
Delete:
Question: What to do with a calendar when a node is deleted?
Decision: If it is the base node and some translations remain, the calendar should be linked to one of the translations. However, to make sure the result remains working, we have to know what Drupal does with the value of tnid for linked nodes.
Error: currently the calendar and settings are deleted.
Update:
Error: installations probably have a lot of excess settings (for nodes linked to the base node)
Question: should we remove excess settings in the variable table?
Decision: no, settings per node are a bad idea anyway. Solve this by switching that feature off, which WILL remove ALL node specific settings.
Comment #2
fietserwinPartly solved (and committed to 7.x-2.x-dev). Settings and id usage has been solved. Cache clearing and handling hook_node_delete remain open.
Comment #3
fietserwinThe new fields based version (7.x-3.x) doesn't have these problems:
Access:
Remains the same. If you may edit a field, you may edit the calendar attached to it.
Cache:
When using i18n_sync, entity_update will be called on all entities within the translation set, so the cache will be cleared for those entities.
Settings:
No settings per node anymore.
View/edit:
Calendar id's are used, no problem anymore.
Delete:
Orphaned calendars remain to exist. A cron job could be created to remove these. For now this is not seen as a problem, but it might get its own issue.