Dynamic Field Control selector - Id or OriginalId

Hi team,

I had some troubles with retrieving related items between 2 Content Types within my Dynamic Module. I was executing this code, to load the related items of a Dynamic Content item:

Then I used this array to retrieve only the items that match:

This was returning 0 results. After a close look I realized that the Guid inside the secretaryIds array was corresponding to the Master version of the item, or better, the OriginalId.

Since I compare to the Id property, which I assume is the Live version of the item, the result always will be 0.

So the question is: should we use the Id property of Content Items when retrieving them through the API, or the OriginalId property? If that is the case, the code inside the generated javascript should be replaced, because the getter and the setter are using the OriginalId, as you can see in the next code:

Getter

Setter

Let me know if I'm wrong, otherwise I'll use the OriginalId for loading the data.

Kind regards,
Daniel

Hi Daniel,

Thank you for using our services.

You are probably developing the related items selector field control following Rado's blog post?
The article has been released to demonstrate the capabilities of the Sitefinity Module Builder feature upon its official release. Since then we've incorporated this functionality withing our Sitefinity Thunder plugin for Visual Studio, so now you can create a related data selector a easy a filling your the two related data types when Thunder prompts you for this information. I believe you might find this article from our documentation, which explains in details how to achieve the above mentioned functionality useful.

On a side note, to answer your question - the DataService which accomodates the CRUD operations with Dynamic Modules int he backend by default operates with the master items, that's why it's better to work with the master item IDs, and get the live items from the master.

Kind regards,
Boyan Barnev
the Telerik team

Hi Boyan,

No, I use the latest version(s) of Thunder and Sitefinity. So I'm talking about the generated code by Thunder itself.

As I explained, if I use the Id property instead of the OriginalId I get no results. So since all examples and documentation about the API are talking always about the Id property to fetch data, I think it should be documented that when you use these selectors from Thunder, you must use the OriginalId, to fetch specific data.

I only want to fetch related data, that is also published and to me it seems not consistent to use the OriginalId instead of the Id?

Kind regards,
Daniel 

Hello Daniel,

The current functionality we're discussing has gone through several iterations in an attempt to achieve the most straightforward implementation. The reason for proceeding in such manner is that in Sitefinity we operate with the master item IDs. That is, the Thunder built selector would automatically filter only the live items (so that you can't select an item that's not live) but will persist the master item's Id.
This has been done to accommodate the out of the box functionality of DynamicContentView to display the related data in DetailsView.

Please do not hesitate to let us know if you need us to elaborate a bit further on the above, I hope it makes more sense now.

Kind regards,
Boyan Barnev
the Telerik team

Hi Boyan,

Then I'm confused. If I use the generated code by Thunder, it does not give me back any results. That would mean that the items I'm trying to fetch are not published (Live), but they are. Well, Sitefinity tells me they are published.

I'll check it again.

Kind regards,
Daniel

Hello Daniel,

The field control selector which Thunder generates will let you select from the live items but it will persist their OriginalContentId properties. The OriginalContentId points to its Master item.

To get the live item, you can use the following code:

@Daniel

  I have been going on with this exact issue for like 2 months...it's like the never-ending ticket from hell.  Client has SO MANY records linked via the thunder-generated widgets, so they fixed the implimentation to be original content ID, now we're totally unable to run the API to fix those bad links...well I mean the code runs, but the results aren't saved.

 The frustrating part is you only get a ticket response every few days and it's like "We're looking into it" or "Can you try"...you know after giving me a generated widget that borked the client data, and spending months on the ticket, can maybe you please just fix the problem and give me a magic script to fix it :/

sorry ...bit of a vent.  The frustrating part for me is I put so much faith in Thunder, then there's a HUGE bug in it they patch...but all the data you've just entered is screwed and there's no fix released...and I get to go back and manually fix all my field controls.

 Here's what you should do...just create a new thunder widget, check the code, and use that...if you're in the situation I am (as defined above), then god help you...you're in for a ride.  I think there's two changes from the old versions.  In the code the service paths now have "/live" on the end (as you can see) and yeah it's linked to the OriginalContentId now.

 Steve

Hi Steve,

Thank you for providing your valuable input to the community.

It is true that the DynamicModulesSelector  field control has gone through several iterations, trying to address client feedback and still make the implementation compatible with Sitefinity standards.

Let's work on the specific issue you're experiencing in the support ticket you have open for it, and you can follow up with the community with the solution once we resolve the problem.

Greetings,
Boyan Barnev
the Telerik team

I am having the same issue with this - I updated sitefinity thunder and this broke all of my content selectors. Please communicate a solution when it arises.

Becca

@Becca,
  My ticket was open for a looooong time with lots of back and forth.  Had code written to loop through all the linked Guids and fix them all...but even after checkout\checkin\publish\etc the data never saved...

The solution for me was to just export the data, delete the module, and re-import.  Theres only so many update scripts that kept borking the data I could take...So telling support that they did provide me with a sample of code to re-import exported module data.  However keep in mind if you go that route, all pages with the old widget need to be edited and replaced with the "new" one (different GUIDS)

This by far has been my worst experience...hellish is an understatement....and technically still going, I'm running the import script as I type this (and hoping it doesn't YSOD)

Steve