Page MenuHomePhabricator

impossible to change the data type of a property
Closed, DeclinedPublic


Author: gloumouth1

Just after having created a property, and chosen its data type, it is impossible to change it. But it should be, if the property is not used yet by any item.

Version: unspecified
Severity: enhancement
See Also:



Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 22 2014, 1:21 AM
bzimport set Reference to bz43643.
bzimport added a subscriber: Unknown Object (MLST).

Is this actually a Wikidata related bug? :/

gloumouth1 wrote:

0) Go on

  1. Click on "Create a new property"
  2. Fill the "Label" field
  3. Choose a "data type"
  4. Click on "Create"
  5. Try to change the "data type" (it is impossible)

Isn't it a Wikidata related bug? :\

It is. Thanks for reporting.
I personally think it is good the way it is. Wouldn't it be confusing to be able to change some and not others?

It can be coded so it can be changed if no items use it yet, but that would open a can of worms. Just imagine all items using a specific property is deleted, the property is then changed - including its type, and then the items undeleted.

The easy solution is to follow a usecase where you always make the type of the property read-only.

I would say close this as a wontfix, as this is the correct behavior.

gloumouth1 wrote:

Consider this use case:

  1. Create two items Q1 and Q2
  2. Create a property Pa with Monolingual text as data type
  3. Create a property Pb with Item as data type
  4. Instanciate Pa for Q1 with "Foo" as text
  5. Instanciate Pb for Q1 with Q2 as linked item
  6. Delete Q1 and Q2
  7. Undelete Q1

--> The instance of Pa will be undeleted as well with the "Foo" as text, but the instance of Pb cannot be undeleted because Q2 does not exist anymore.
So I think that the "worms" that you speak about already exist...

I just say that:

  1. when you just created a property 2 seconds ago, you can modify every thing, except the data type, which is quite disturbing for the user.
  2. when an undelete is demanded, yes, some checks are needed, but it is already the case, before my code modification request.

Changing from unconfirmed to New. This is a feature request for a sensible feature.

I do not think it is urgent: don't forget that you can rename properties. This can resolve many of the issues that would be wanted otherwise.

After Lydia pointed me to this, I agree that it is a sensible feature to be concluded while not urgent. It is definitely worth considering to making the Property namespace more manageable rather than having properties scattered around being deleted due to an accidental data type.

As Denny said it can be solved by re-creating and deleting but really changing the original datatype would be much more user-friendly and would allow everyone with the ability to create properties solve accidental datatype assignments.

Lydia_Pintscher removed a subscriber: Unknown Object (MLST).
Lydia_Pintscher removed a subscriber: Unknown Object (MLST).
Lydia_Pintscher claimed this task.

Ok let's be realistic. It hasn't been done in 2 years - it's not getting done. The marginal usecase we could cover (only do this for properties that are not in use anywhere) isn't worth the implementation cost and confusion it would cause.
Sorry :/