Because we need to let site-specific custom parsing code (e.g. the versioncontrol API label_version_mapper plugin from drupalorg_versioncontrol) know how to convert a given Git tag into the right version components, project_release_node_presave() cannot be parsing the full version string and automatically setting the version element fields itself. We should let the form specify that the subfields should be left alone (or set to specific values that don't match the default version parsing).

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dww’s picture

Assigned: Unassigned » dww
areke’s picture

Issue summary: View changes
dww’s picture

This is more or less working, but #2145675: Alter the release node form to set values for the version element fields as determined by the label_version_mapper plugin is a bit of a mess (at least on my local dev site, not on a d.o clone) and I don't want to commit/push anything here until I resolve that.

However, one problem I realized is that in cases where the version string is editable on the release node, if we're *not* re-parsing and saving the sub-element fields, you could easily get into a state where the version string no longer matches the sub-elements. :( Not sure what we should do about this. A few possibilities:

A) Control this presave behavior with some kind of flag in the $node object. Let it default to re-parsing each time, but if the flag is set, leave the values alone.

B) Control this presave behavior with a configuration knob. Seems evil and wrong.

C) Ignore it and punt. It's rare you'd ever be changing these values once the node exists, so let it be broken in you do something wonky. But, ugh.

Of these 3, I think A would be best. Forget about trying to see if there are existing values or not, rely on a new flag that's set via the form, and let versioncontrol_release set that flag when it's setting the sub-elements itself. versioncontrol_release would also need to alter the edit form (which it already does) to set this flag to prevent project_release from breaking things on a regular node edit.

@areke -- I appreciate your desire and willingness to help, but I don't really understand the summary edits from #2 -- seems like busy-work to me. If you're going to re-write issue summaries, please work on summaries that are either a) very out of date or b) complex. This one is simple and current, so it doesn't really need to be edited to conform to a template that's really intended for larger issues.

Thanks,
-Derek

dww’s picture

I pushed a few minor/obvious commits to clean up a few things I found while working on this:

http://drupalcode.org/project/project.git/commit/ebb66cd
http://drupalcode.org/project/project.git/commit/08c9a6e

Then, while working on #2145675: Alter the release node form to set values for the version element fields as determined by the label_version_mapper plugin I discovered that since the form elements for the version subfields are generally configured to use the 'hidden' widget, it's a pain (impossible?) to set the values directly via altering the form. So, instead of a simple boolean flag, you can set the version subfield values in an array and project_release_node_presave() stuffs those values into the node. Not super clean, but working via local testing. If someone has a better idea, I'm happy to code it up, but since this is now working, I don't think it's wise to spend a bunch more time on this.

drumm’s picture

Status: Needs review » Reviewed & tested by the community

Looks good on reading code.

dww’s picture

Status: Reviewed & tested by the community » Fixed

Pushed http://drupalcode.org/project/project.git/commit/7bdf6fe and deployed live.

Thanks!
-Derek

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.