Allow control the source of field in portal indiv.

[jakSolutionsGithub]

No description provided.

[fuzzzerd]

I've approved the actions to run on this PR and there are a couple of issues. If you can get those sorted out I'll try to take a look at the code once everything is passing.

[jakSolutionsGithub]

Should be good now.

[fuzzzerd]

This looks like a quite promising start! Can you please add a test case that covers this new feature as well so we can ensure it isn't broken by future changes?

I have been mocking the Data API Responses in a JSON file and loading that in at test time, here is a current test that can serve as a starting point. A few modifications to a clone of this test should get us there:

fmdata/tests/FMData.Rest.Tests/Find.SendAsync.Tests.cs

Lines 168 to 195 in 564a209

	[Fact]
	public async Task SendAsync_Dictionary_WithPortals_ShouldHaveData()
	{
	// arrange
	var mockHttp = new MockHttpMessageHandler();
	var layout = "the-layout";
	mockHttp.When(HttpMethod.Post, $"{FindTestsHelpers.Server}/fmi/data/v1/databases/{FindTestsHelpers.File}/sessions")
	.Respond("application/json", DataApiResponses.SuccessfulAuthentication());
	mockHttp.When(HttpMethod.Post, $"{FindTestsHelpers.Server}/fmi/data/v1/databases/{FindTestsHelpers.File}/layouts/{layout}/_find")
	.Respond(HttpStatusCode.OK, "application/json", DataApiResponses.SuccessfulFindWithPortal());
	var fdc = new FileMakerRestClient(mockHttp.ToHttpClient(), FindTestsHelpers.Connection);
	var fr = new FindRequest<Dictionary<string, string>>
	{
	Layout = layout
	};
	fr.AddQuery(new Dictionary<string, string> { { "one", "one" } }, false);
	// act
	var response = await fdc.SendAsync(fr);
	// assert
	Assert.NotEmpty(response.Response.Data);
	}

[fuzzzerd]

@jakSolutionsGithub, @korpinz -- just wanted to follow up and see if you saw my note about adding some test coverage for this change?

[jakSolutionsGithub]

@fuzzzerd -- Yeah, will try to take care of it this weekend!

[fuzzzerd]

I am inclined to approve this change, once covering unit tests are in place.

[HollowGraphic]

Is this still being worked on? I'm pretty sure I'm running into this limitation currently. I can think of a work around but I'd rather not. To be sure though, how many "levels" deep can we use the PortalData attribute? The one that's failing on me is on a layout that itself comes from a portal.

[fuzzzerd]

Is this still being worked on? I'm pretty sure I'm running into this limitation currently.

I suspect this fell off @jakSolutionsGithub radar. I had requested the addition of some test coverage for this change. Once we have that I'd be inclined to approve it and create a release.

I can think of a work around but I'd rather not. To be sure though, how many "levels" deep can we use the PortalData attribute? The one that's failing on me is on a layout that itself comes from a portal.

Do you mean a portal within a portal? I'm not sure how FileMaker handles that specifically; however, the PortalData attribute just helps guide the serializer, so it should just work as long as the data structure matches.

[HollowGraphic]

Okay, thanks. I did mean portal within a portal. I've tried a couple of things and have not been able to grab the data from embedded portals. I know the FM community has stated that portalception is not supported by FM, but, it does look like it works on the FM side. It displays the correct records. I guess I'm not sure if its doable.

[fuzzzerd]

Feel free to open another issue or discussion on the topic. I haven't done much with portals myself, but I'd be open to exploring the possibility and finding out what itd take to get it working.