Restrict number of Repeat Records when "food runs out"

[Teresa_Blader]

I'm newish to repeats, and I'm working on a survey connect for "food rescue", and want to limit the number of repeats available in different scenarios.

Project Structure: There will be two surveys in the workflow pointing to the same feature layer with relate table (one survey for donors, one for rescuers)

1. Donors (restaurants/grocers) submit a food donation... each row is a new donation (repeat is hidden in their survey). They input an approximate weight. They also decide if they want to allow multiple claims for one donations... split it up per say. 

2. Rescuers (pantries/shelf) open experience builder app > see Available donations > click "claim" button on a donation in list, which opens a different version of survey... now showing the repeats. If allowed by donors, Rescuers can claim part of the donation, by designating what percentage they will claim. (select_one likert ...10% - 90%)

This then calculates outside the repeat (donation weight - (sum of percent's from repeat  x donation weight))... to show how much is remaining...

That is used to then determine if the donation is Available, Claimed, or Part Claimed... outside of the repeat. 

What I'd like help with is setting up the repeats for the rescuers to:

1. Restrict to one repeat record if the donor didn't allow splitting. ${order_split} = 'No' repeat_count = 1

2. Turn off adding more repeat records once the remaining donation is zero or "claimed". ${Remaining} <= 0 and ${order_split} = 'Yes' 

Do I just write a complex if statement in the repeat_count field? Or do I add this to the relevant field to "hide" the repeat when at zero? I imagine I've limited the donation to 9 repeats with the percents select one... so setting repeat_count to 9 is better than nothing... but not quite there.

Thanks!! 🙂

[DougBrowning]

In my experience if you change the repeat count using a formula on the fly it goes bad.  Since it loads them all at once, if you change it dynamically, then it tends to wipe data.  It has been some time and maybe your workflow is different but it would require a lot of testing.  If it is a one time at the beginning it may work.

I use only things like count() and a constraint with a red note message.  Or even an emoji.

Your other idea - If you try to use relevant then it would wipe the data on you also.  This approach may work using Esri::visible field however.

I would almost consider going no repeat and limit the split.  Like have say 4 sets of fields and use relevant to only show how many they want to split.  Not uncommon to limit the max split.

Hope that helps

[MattEdrich]

A slightly less code-snazzy approach to this would be creating two data-capture blocks: one (a group) utilized for donations that weren't allowed to be split, and the other utilized for those that are rescuing a percentage of the food. Though the two blocks would be mostly identical, this would probably be best accomplished by putting each one on different survey pages to make the distinction clear.

I believe the 'splitting disallowed' pathway is pretty straightforward; however I think it would be prudent to make it a group instead of a repeat if you are planning on setting repeat_count=1.

The 'splitting allowed' pathway is slightly more nuanced:

• You'd need a row to store the initial (100%) amount available to donate, which would be above the repeat block in your XLS sheet
• The repeat block itself would look pretty much the same as you have currently; however you could remove the question about accepting the whole donation since it is implied by them filling out this particular survey block that they are not.
  • A calculate field at the end of the repeat block could determine the weight of the rescued food per repeat record (initial * % rescued) 
  • This ^^^^^ combined with a second calculate outside the repeat block could sum the 'rescued' values of each calculate record.
• Applying ${intial_amount} > ${sum_of_rescue_weights} to the relevant column of the repeat would (I think) accomplish your goal....
  • ...however it would be important in data verification to report that any instance of ${sum_of_rescue_weights} > ${initial_amount} actually just mean that the entire amount available was indeed donated

Something like this could be worth a try! When I first started with S123, I was really trying hard to make everything as fancy as possible so that if another programmer looked at my sheets, they would be like "wow....slick!". However, experience has shown me that - especially when it comes to controlling repeats - it is much easier for you, easier to follow, and faster to code, to duplicate near-identical repeats and then manipulate each one to the specific, simplified parameters it needs to fit. Almost always, this is answered by asking yourself "what story is told by the data in this repeat?". Also, importantly, this approach has yielded extremely predictable outputs.

Good luck, hope this comment helps!

[Teresa_Blader]

I'm not really familiar with splits at all... so I'll have to explore what those are, what they do, and why they're used. 🤔 I have all of the suggested field and calculations already implemented, some on other pages. 

However between Doug and Matt... it sounds like "relevant" wipes the related records? Sounds like I'll have to give'r a test.

A priority is having one row per donation in the database, with the pantries that receive each donation in a relate table. If anything, I'd eliminate the "split donation" option altogether, but something I'm exploring. 

[MattEdrich]

As long as the expression in relevant evaluates as true, the data will remain intact as it was gathered. However, the moment that a repeat's relevant expression evaluates to false, the repeat itself is "turned off" and it is as if it never existed in the first place. This means that if you collected 5 records in the repeat, and then it became "irrelevant", all five records would be wiped; restoring the repeat to "relevancy" in the same form will not restore the data that had already been gathered, and you will have to begin again at the first record.

With that said, that makes my previous suggestion.....irrelevant! Hah...and sorry. Now that I have thought more about it I don't think your solution will be through using relevant