cubicweb #1381382 regression: supressing a non committed relation in the web interface fails [resolved]

Steps to reproduce:

  • in a Forge instance, edit a Ticket
  • add a relation on that ticket (e.g. "identical to"), do not apply or validate
  • add another relation on that ticket, do not apply or validate
  • click on the [X] in front of one of the non committed relations : the name of related entity is striked through
  • validate or apply

Bug : both relations have been committed.

I cannot reproduce this on an instance running 3.9.9, but instances running 3.10.5 have this behavior (could not test with earlier 3.10.x versions)

priorityimportant
typebug
done in3.10.7
load0.500
load left0.000
closed by<not specified>

Workflow history

from state (3)to statecommentdateUser
validation pendingresolved2011/05/27 14:25 UTCsthenault
donevalidation pending

version publiée

2011/01/13 18:17 UTCsthenault
opendone

checked that the issue is still there in 3.10.6 and fixed in stable head.

thanks

2010/12/03 14:13 UTC 

Comments

  • 2010/11/18 22:00, written by sthenault

    tied to 3.10 jQuery version update?

  • 2010/11/24 09:55

    This is a very baaaaad bug because on some relation with a 1 cardinality, a previously linked entity will no longer be linked, causing corruption of the DB.

    • 2010/12/01 15:36, written by sthenault

      could you detail this?

      which entity has the 1 cardinality ? the edited entity or the target entity ?

      can I reproduce it on a forge instance ?

  • 2010/12/01 15:49, written by sthenault

    huum, I can't reproduce the described pb (eg without talking about unrespected cardinality).

    The thing is that, as I expected, when I remove a not yet commited relation, the link is not striked but disappear totally. And then everything seems ok to me.

    • 2010/12/02 07:39

      I've just reproduced this issue on this very ticket, with two "identical to" relations although one had been deleted before I clicked on Validate.

      • 2010/12/02 07:40

        I'll be happy to discuss this with you over the phone, if you think it will help.

      • 2010/12/02 09:16, written by sthenault

        ok, I've reproduced this one and pushed a fix in stable branch. Still fail to see the potential db corruption pb though.

        Can you check the fix and mark this ticket as done if it's enough?

        thx

        • 2010/12/02 14:38

          the db corruption pb occurs in the following case:

          • the schema defines A rel B and A can be related to 0 or 1 B
          • I edit a B entity, change some attribute values, browse for an A entity to be linked with my B entity, select an A entity
          • I realize that I selected the wrong A entity, so I click on the "X" to cancel that association
          • at that point I decide to Apply the changes : the relation with the A entity is established. If that entity was previously related to another B entity, that relation is lost, and I have to easy way to restore it.
          • 2010/12/02 18:06, written by sthenault

            ok. So we agree that:
            * it's not db corruption in the sense of non respected constraint causing integrity error
            * we may consider everything is fine once the described bug is fixed

            Have you tried the fix ?

            • 2010/12/03 07:36

              no, it is db corruption in the sense that I asked something, got something else and can't revert the change.

              didn't get a chance to reproduce (my instances are running 3.9), will try today.

add comment

Ticket #1381382 - latest update on 2011/05/27, created on 2010/11/17