0x2620/pandora

Fork 1

Adding entities to a document does not persist properly #2769

New issue

Closed

opened 2015-04-27 16:22:37 +00:00 by wjt · 6 comments

wjt commented

2015-04-27 16:22:37 +00:00

Steps to reproduce:

a) Data → Manage Documents…
b) Select a document
c) Start typing a participant, accept the autocomplete suggestion
d) Click Done
e) Re-open Data → Manage Documents…, and reselect the document
f) Be very disappointed that the tag has vanished

The editDocument request is sent with this data:

 {
  "id":"A",
  "undefined":[["participants","Joe Bloggs"]],
 }

It's not immediately obvious (to me) from static/js/documentsPanel.js where the undefined is coming from.

Steps to reproduce: a) *Data → Manage Documents…* b) Select a document c) Start typing a participant, accept the autocomplete suggestion d) Click *Done* e) Re-open *Data → Manage Documents…*, and reselect the document f) Be very disappointed that the tag has vanished The `editDocument` request is sent with this `data`: ``` { "id":"A", "undefined":[["participants","Joe Bloggs"]], } ``` It's not immediately obvious (to me) from `static/js/documentsPanel.js` where the `undefined` is coming from.

wjt added the

frontend

label 2015-04-27 16:22:37 +00:00

wjt added this to the 14.04 milestone 2015-04-27 16:22:37 +00:00

rlx was assigned by wjt

2015-04-27 16:22:37 +00:00

wjt added the

normal

defect

labels 2015-04-27 16:22:37 +00:00

wjt commented

2015-05-14 13:24:57 +00:00

Author

The undefined is because no id is provided here: http://code.0x2620.org/pandora/annotate/4965/static/js/documentsPanel.js#L678

But it is a red herring. The actual issue is that this call to findEntities http://code.0x2620.org/pandora/annotate/4965/static/js/documentsPanel.js#L769 returns nothing. If I make the same query with {key: 'name', value: entity.name, operator: '='} (ie contains), it returns the entity.

I think this is caused by pandora revision 4918 mapping queries against name to name_find: http://code.0x2620.org/pandora/annotate/4965/pandora/entity/managers.py#L8 . If operator == '==' then the resulting query will be name_find__iexact="Foo" – which is guaranteed to fail, since the entity has name == "Foo" but `name_find == "|Foo|

I guess the intention was to make findEntities treat a query against name as matching any of alternativeNames too, which works fine for substring matches. I think the only thing for it is to share the |%s |%s| %s| etc logic from autocompleteEntities.

The `undefined` is because no `id` is provided here: <http://code.0x2620.org/pandora/annotate/4965/static/js/documentsPanel.js#L678> But it is a red herring. The actual issue is that this call to `findEntities` <http://code.0x2620.org/pandora/annotate/4965/static/js/documentsPanel.js#L769> returns nothing. If I make the same query with `{key: 'name', value: entity.name, operator: '='}` (ie contains), it returns the entity. I think this is caused by pandora revision 4918 mapping queries against `name` to `name_find`: <http://code.0x2620.org/pandora/annotate/4965/pandora/entity/managers.py#L8> . If `operator == '=='` then the resulting query will be `name_find__iexact="Foo"` – which is guaranteed to fail, since the entity has `name == "Foo"` but `name_find == "|Foo| I guess the intention was to make `findEntities` treat a query against `name` as matching any of `alternativeNames` too, which works fine for substring matches. I think the only thing for it is to share the `|%s` `|%s|` `%s|` etc logic from `autocompleteEntities`.

wjt commented

2015-05-14 16:15:28 +00:00

Author

Attachment 0001-Entity-fix-name_find-when-alternativeNames-is-non-em.patch (1109 bytes) added

Entity: fix name_find when alternativeNames is non-empty

**Attachment** 0001-Entity-fix-name_find-when-alternativeNames-is-non-em.patch (1109 bytes) added Entity: fix name_find when alternativeNames is non-empty

0001-Entity-fix-name_find-when-alternativeNames-is-non-em.patch

1.1 KiB

wjt commented

2015-05-14 16:15:43 +00:00

Author

Attachment 0002-Fix-findEntities-.-name-x.patch (2463 bytes) added

Fix findEntities( ... name == x ... )

**Attachment** 0002-Fix-findEntities-.-name-x.patch (2463 bytes) added Fix findEntities( ... name == x ... )

0002-Fix-findEntities-.-name-x.patch

2.4 KiB

wjt commented

2015-05-14 17:12:33 +00:00

Author

With these patches it's possible to associate entities with a document. The form can get a bit confused because item.entities is not updated (cf the fixmes in documentsPanel.js) but this is a start.

(I think it's a bit surprising that you can't edit the entities for a document using editDocument but that's another story.)

With these patches it's *possible* to associate entities with a document. The form can get a bit confused because item.entities is not updated (cf the `fixme`s in `documentsPanel.js`) but this is a start. (I think it's a bit surprising that you can't edit the entities for a document using `editDocument` but that's another story.)

wjt commented

2015-05-14 17:23:13 +00:00

Author

Attachment 0003-Fix-references-to-findDocument-s-in-docstrings.patch (2578 bytes) added

Fix references to findDocument[]s in docstrings

**Attachment** 0003-Fix-references-to-findDocument-s-in-docstrings.patch (2578 bytes) added Fix references to findDocument[]s in docstrings

0003-Fix-references-to-findDocument-s-in-docstrings.patch

2.5 KiB

wjt commented

2015-05-20 10:30:36 +00:00

Author

In []changeset:pandora,4981:

#!CommitTicketReference repository="" revision="pandora,4981"
Fix findEntities( ... name == x ... ), fixes #2769

In []changeset:pandora,4981: ``` #!CommitTicketReference repository="" revision="pandora,4981" Fix findEntities( ... name == x ... ), fixes #2769 ```

wjt added the

fixed

label 2015-05-20 10:30:36 +00:00

wjt closed this issue

2015-05-20 10:30:36 +00:00

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: 0x2620/pandora#2769

No description provided.