Last modified: 2014-03-11 15:45:36 UTC
Claims on pages contain a property -> value (item, string, etc). At the moment it's only possible to update the right hand side of this. If you want to change the left hand side you have to remove the existing claims and add new ones. It would be nice if it would also be possible to update the left hand side.
I am pretty sure we have another bug for this but can't find it right now. All in all I am not convinced we should do this. How would you for example handle the change to a property of a different datatype?
(In reply to comment #1) > How would you for example handle the change to a property of > a different datatype? Depends on in which edit mode the property can be changed. Can it be changed per claim or for all claims fo a claim group (for all claims using the same property) at once? I guess the simplest way to implement this would be allowing to change it for only one claim, the one in edit mode. The claimview even has a property selector already, we are just hiding/locking it when editing an existing claim.
Use case for me would be edits like https://www.wikidata.org/w/index.php?title=Q1895068&diff=84189247&oldid=18436211 . Right hand side is correct, but wrong property on the left.
I guess in most cases you want to actually change the claim for the whole group of claims. This is more tricky, I have no idea where the edit controls for this should live right now.
(In reply to Lydia Pintscher from comment #1) > I am pretty sure we have another bug for this but can't find it right now. This feature request is already covered in bug 44639. Should we close this as a duplicate? Personally I don't think we should allow editing properties in snaks, at least not at the moment. Replacing a property with an other property of an other type would cause the same issues as discussed in bug 43643. If we do allow editing it probably needs to be restricted to propertys of the same type. It doesn't make much sense to switch a date into a media file name, for example.
*** Bug 44639 has been marked as a duplicate of this bug. ***
I've been thinking about this more and we definitely should not do this at the moment. We might revisit the decision at a later point.
