nuPickers icon indicating copy to clipboard operation
nuPickers copied to clipboard

Relations Only Save Format

Open Hendy opened this issue 9 years ago • 39 comments

Since changing the relation mapping behaviour in v1.5.0 the Relations Only Save Format no longer works (see:http://our.umbraco.org/projects/backoffice-extensions/nupickers/questionssuggestions/66666-dotnetcheckboxpicker-relation-mapping-does-not-work#comment-222190)

Hendy avatar Jun 23 '15 08:06 Hendy

There is still a bug here. Saving once properly saves the relation, but saving again removes it.

"picker.SavedValue" is null on the second save, causing the relation to be removed.

dgx avatar Jul 01 '15 16:07 dgx

@dgx thanks for the feedback :+1: I'll investigate again (pretty sure I had tested multiple saves)

Arh I think I know what's happening, because the value is wiped, if the item is saved again without the picker being changed then the value stays empty, and the server side event will wipe the relation. Perhaps the fix is to force the save value to be set on load.

Hendy avatar Jul 01 '15 18:07 Hendy

I'm experiencing the same issue. Did you get the chance to look more at this ?

"Save and Publish" and "Save" both creates and keep existing relations . "Publish" removes existing relations. Publish removes existing relations because property is null when retrived at event handler. It looks like the "Publish" action in umbraco runs this action. Because the "relation only" doesn't save any data to the node the "relationProperty" is null.

I could not find any solution to this problem because i dont know what triggered the "ContentService.Saved" event. I thought i might retrive the node relations through the relation service and add it to the published node if the event triggering ContentService.Saved was "Publish".

Any ideas @Hendy?

torleifhalseth avatar Jul 09 '15 14:07 torleifhalseth

We're also seeing this issue. Hoping to see it resolved as it's a great feature.

aztekweb avatar Jul 17 '15 19:07 aztekweb

Any movement on this issue?

dnwhte avatar Aug 06 '15 17:08 dnwhte

Hi @danwhite85, thanks for the reminder - hopefully it won't be too tricky to fix - as above, we could always re-inflate the value so that it's saved then wiped - or perhaps, always save the value,and just ignored it when querying ?

Hendy avatar Aug 06 '15 17:08 Hendy

@Hendy could we help in some way? I would love to solve this asap.

enkelmedia avatar Sep 06 '15 11:09 enkelmedia

Hi I got the issue as well with the XmlPrefetchListPicker. Did someone find a solution ?

mrflo avatar Sep 15 '15 13:09 mrflo

Any luck solving this issue @Hendy?

torleifhalseth avatar Sep 18 '15 07:09 torleifhalseth

Any news on that?

alecrt avatar Nov 03 '15 11:11 alecrt

Hi folks, just wondering if there's been any movement on this and/or when the above fix might see it make it's way into a release? One of my clients is having big problems with this. If push comes to shove I'll write my own property editor to solve their problems but I do like me some nuPickers. :) Thanks for all your hard work.

pantryfight avatar Feb 15 '16 01:02 pantryfight

Hi @pantryfight I'd like to be able to fix this as soon as possible (as it's a significant issue), but I think we still need to figure out exactly how relations should be working to be able to refactor, so unfortunately I can't give you a date / time, other than in the next release.

@vnbaaij has submitted PR #105 as a quick fix (but ideally we would rather not have to save the value)

Do you have any thoughts on the best approach to fix ?

Thanks, Hendy

Hendy avatar Feb 15 '16 10:02 Hendy

Several days ago in a separate thread, @Hendy suggested that perhaps the solution would be to run the original AJAX save routine UNLESS it is a new node (Id=0), in which case, the newer server-side routine would handle it. (https://github.com/uComponents/nuPickers/issues/130#issuecomment-178885976)

So, for those of you on this thread with some skills & time, perhaps you can investigate that possibility? I'd look into this, except that I'm not as familiar with the internals of how the AJAX used to run, so someone else would probably be able to fix it quicker than I right now :-)

Incidentally, I have a site going live within the next couple weeks that has this serious problem, and if I can't figure out a reasonable solution very soon, I'll have to re-work this relation to instead be a MNTP. I'd rather not, but data stability is critical, after all.

I wonder if I change the picker to use a "Save Format" other than "Relations Only" - will that fix the issue? (Since the picker wouldn't be showing as "NULL" on content-node save?) Does anyone have any experience where that was NOT a good idea?

Thanks, everyone!

hfloyd avatar Feb 19 '16 17:02 hfloyd

@Heather the problem with the server side code is that it performs a save of the content node for every picker property in th doctype. Not only slow but also leaves the node in an incorrect state after saving. My pr disables this behavior. It does however duplicate the data saved: once as csv in the property and a record for every relation selected. Something we can live with very well in our solution. We don't use the csv value in our rendering, but use the relation data for that

vnbaaij avatar Feb 19 '16 21:02 vnbaaij

@vnbaaij : I'm not the one best positioned to make a decision on the right fix for this issue, since I'm not familiar enough with the code. I just wanted to reference @Hendy's latest comments about it, to keep the conversation moving. Thanks for your contribution.

hfloyd avatar Feb 22 '16 16:02 hfloyd

I encountered the problem with the latest release, where for the first initial save is alright but when deleting and modifying, it is not working well, related to relationships.

Any idea when this fixed will be soon fixed?

Thank you.

simoazzo avatar May 19 '16 20:05 simoazzo

Hendy,

When the next release will be issued?

simoazzo avatar May 23 '16 14:05 simoazzo

Hi, May I ask when this bug issue will be solved please for the next release?

thank you.

simoazzo avatar Jul 12 '16 06:07 simoazzo

Hi @simoazzo, yes it'd be great to get the next release out with this fixed, but unfortunately I can't give you a particular date.

Hendy avatar Jul 12 '16 08:07 Hendy

Hi Hendy,

Hope this message finds you well.

Can you please give me an updated on this fix because I have a live website which is having such issues due to this bug in nuPickers. Appreciate so much a fix as soon as possible.

Thank you and Kind Regards Simon

simoazzo avatar Jul 21 '16 10:07 simoazzo

Hi @simoazzo, unfortunately I've not spent any time looking at this issue recently - is this something you could help solve ?

Thanks, Hendy

Hendy avatar Jul 21 '16 10:07 Hendy

Hi Hendy,

I wish that I can help, but I don't have so much time to fix it. As I seen above, the issue has been for a long time but I don't know exactly what is happening. For an older real ease everything is working fine, but the latest relaxer no. There is something wrong when edit or delete relationships.

I would be very happy if you can sort this out, because as you said in the previous posts, it is a significant issue..

thank Hendy.

Appreciate.

Kind Regards

simoazzo avatar Jul 21 '16 12:07 simoazzo

Hi Hendy,

Are there any updates on this please?

thank you

Kind Regards

simoazzo avatar Aug 03 '16 10:08 simoazzo

Hi @dgx @thalseth @aztekweb @danwhite85 @enkelmedia @mrflo @alecrt @pantryfight @hfloyd @vnbaaij @simoazzo Sorry it's taken so long to fix this ! but it'll be out in the next release (v1.6.0).

(You can also find it in the latest prerelease, which also includes the caching of picked 'relation only' values so there's no subsequent db hits on the front-end) NuGet Package: MyGet build Umbraco Package (zip file): AppVeyor Artifacts

Hendy avatar Apr 05 '17 22:04 Hendy

I still have problems with LucenePrefetchListPicker and Relations Only save format.

In the backend I have a list-view of nodes each with a property of type LucenePrefetchListPicker - save only format. When I edit one of them and then press Save & Publish button, the page seems to be saved and published correctly but if a look back in the list-view it's only saved but not published. If I take a look at the public published page, in fact, changes are not visible.

If I then publish the page directly from the listview, the publish process works fine, all changes are reflected except the LucenePrefetchListPicker property data which is wiped out.

Any ideas?

alecrt avatar Apr 19 '17 12:04 alecrt

Hi @alecrt I'm not sure I understand the issue you're having related to nuPickers - when using the Relations Only save format, the saved data is indeed wiped (this is to avoid having duplicate data which may become stale - the main source of the data for all pickers of this type is then the relations data, and not a local saved value).

Hendy avatar Apr 19 '17 12:04 Hendy

@alecrt I should add, that to retrieve the values, you can let the PropertyValueConverter handle returning a Picker obj for the current context (which you can then use the .PickedKeys property), or you can create a Picker obj using the extension method in nuPickers.Extensions on IPublishedContent. eg. content.GetPicker("alias"); or you can create a Picker obj with new Picker(id, "alias"); HTH, Hendy

Hendy avatar Apr 19 '17 12:04 Hendy

Hi Handy,

thank you for your fast reply. The problems i have are two:

  • the first one is ralated to publish. I can't publish a page with a property of type LucenePrefetchListPicker - save only format from page edit-form. As I said no error appears, but the page seems only saved and not published to the xml cache.
  • the second one is publishing from outside the page itself: i.e. from the listview. In this case publish works fine BUT the relations are removed from umbracoRelation table.

alecrt avatar Apr 19 '17 13:04 alecrt

  1. when you save and publish are other property editors saving to the XML cache ? (the LucenePrefetchListPicker in Relations Only save format, will not save a value locally into the XML cache), so I'm not sure on the issue here.

  2. this sounds it could be an issue with nuPickers (I've never tried relations only in a list view, but can't see what difference this should make - as I'd expect the same save event with same parameters). I'll setup a test and investigate.

Hendy avatar Apr 19 '17 13:04 Hendy

  1. yes, DB speaking: all other properties has been saved correctly in CmsContentXml table and versionId matches the latest cmsContentVersion for the node. What it's weird is in cmsDocument table: the newest version IS NOT the published one. Like the node was only saved but not published.

  2. Thank you!

alecrt avatar Apr 19 '17 13:04 alecrt