Option to retain invalid value on edit
| Project: | Content Construction Kit (CCK) |
| Version: | 6.x-2.x-dev |
| Component: | nodereference.module |
| Category: | feature request |
| Priority: | minor |
| Assigned: | Unassigned |
| Status: | won't fix |
Weird feature request, but basically, I'd like an option to retain invalid value on edits if they'd been valid (ie match the old value).
The reasoning behind it is the ability to have 1 to 1 relationship for nodes via nodereference.
I have ct2 that with a node reference to ct1. I have an advanced view suppling NIDs to node reference. The view excludes all ct1s that already have a node reference to ct2 (given certain conditions).
The problem is not on creation; that works fine; but later editing and trying to resave the node it will always fail validation since the view no longer has it cause the node has it. Can't figure out a way around this in views :(.
For a real example, I'm making an online gear tracker for a mmorpg I play, and ct1 is a "gear" while ct2 is a "borrowing record", and well, a gear can't be borrowed more than once at the same time (using workflow for borrow, lost, returned states). And yeah, can't edit the borrowed instantaneous until I mark as returned.
So basically, an option to retain old values even if invalid. Is this a useful or valid feature request? If not I'll just do a workaround specific to myself. I hate hacking cck though, annoying when upgrading.
#1
Here, attached is basically what I desire. Done against nodereference, latest release cck(6.2.?).
Adds one checkbox to form, under advanced. Likely evens out as far as speed goes, since it doesn't call _nodereference_potential_references if there's no new referenced nodes.
#2
I think you should find a way to ignore the noderefs in the current node from the view. One possible way would be to use some kind of views argument that you dynamically customize using a views hook with the nid of the node being edited (taken from the URL, for example), or something on that direction.
PS: This is not a CCK3 issue.