When I edit a node and I choose to apply the edits to either "This occurance and all future occurances" or "All occurances", some fields (like Title and Body) are changed in all repeated nodes but some fields (like "moderate" and "user") are not.

I have looked in the code and I've seen that, for safety reasons, only the title, teaser and body are copied. This is quite problematic since I might have some content types that have other fields. Plus, the behavior is different from the behavior when creating repeated nodes: when you create a series of nodes, fields like "moderate" and "user" ARE copied. This is just not consistent IMHO.

Comments

seanbfuller’s picture

seanbfuller commented

Known issue and I plan on looking into this once the edit bug has been resolved in cvs version. Hopefully, this will be soon.

seanbfuller’s picture

seanbfuller commented

As an update on this issue, I'm currently working through the implications of what would happen if eventrepeat copied everything except the list of known things it should not send on. I'm trying to figure out if this would solve some issues where other modules want to add information into the replicated event nodes, or if it might cause problems down the road. My biggest concern right now is how relationships would be affected. Hoping to get back with some code soon.

scott.mclewin’s picture

scott.mclewin commented

Shawn - I want to give you compliments on your position with this issue as compared to those of the previous maintainer, who just dismissed this editing problem. After a study of the eventrepeat code I do agree that this is not an easy issue to address because of the referential integrity problems it may introduce. I tried to find an elegant solution to submit as a patch. I didn't. I did find an inelegant solution.

I do think it would be wise to disable the "edit this and all future occurances" option when editing, or give it a link that describes the significant limitations of the feature.

An expensive and inelegant solution would be to seralize the new complete version of the node into the appropriate event_repeat table row, then delete all future nodes in the series (which have not been indivudlally altered) when this option is selected and allow the natural flow of the eventrepeat logic to re-create them. It will certainly churn nodes quite a lot, and I've found it can take more than a typical-default-web-server-timeout worth of time to delete all of the future nodes.

seanbfuller’s picture

seanbfuller commented

Possible solution here:

http://drupal.org/node/87596

Please test if you get a chance and let me know how it goes:

scott.mclewin’s picture

scott.mclewin commented

Sean - apologies, but since I reworked a non-node-copying version of eventrepeat I'm no longer running the eventrepeat module anywhere and don't have a test bed handy. From the other thread it appears you have a few testers.

seanbfuller’s picture

seanbfuller commented
Status: Active » Postponed

Postponing this issue as it should be handled by this committ to cvs head: http://drupal.org/node/87596

Once we catch up and current cvs goes to 4.7, I'll mark it closed.

seanbfuller’s picture

seanbfuller commented
Status: Postponed » Closed (won't fix)

Marking this as won't fix for 4.7.x-1.x. You will probably want to upgrade to 4.7.x-2.x, which should be posting soon. (Most of the issues that are left in the 2.x version were present in the 1.x version as well.)