Conditionally change text style - an entity issue?

Support
6

:see_no_evil: I think we forgot that double quotes are allowed and only detect instance expressions with single quotes currently. Will try to fix that for the next Central release.

@ahblake I wonder whether this might be why you were seeing some expressions that worked as expected and others not.

That's fair. You could do something like use a note_ prefix and filter those out automatically in your analysis. We'll likely add an option like that at some point.

Yes, I would probably put each pair in a field-list so they're clearly grouped.

Here's a brief summary of the highlights from the Insiders Office Hours:

  • We discussed one of @seewhy's needs around footpaths. There's an in-depth assessment of these paths every 5 years and then some ongoing maintenance or other todos related to individual paths in between.
  • If there was only the assessment on a 5 year schedule, I would probably recommend using a manually-attached CSV to get data from the last assessment into the current assessment.
  • Because there is also the possibility of ongoing work to do with paths, it's likely worth it to have an Entity List representing those paths. That way any form that does path-related work can use that same list with up-to-date data. Certain forms can update its properties like maybe a "last visited date".
  • Path Entities likely can have a small number of properties representing unchanging aspects of the paths. Their role is to help identify the right path in a form and to connect form submissions about the same Entity.
  • For the 5-year assessment, there's a desire to make past data accessible. My suggestion is to use a separate Entity List for that. It could be named something like path_assessments.
  • Each path_assessment Entity would have a path property that stores the id of the path that the assessment is about. It would also have a property representing the assessment year. That would make it possible to write expressions like instance('path_assessment')/root/item[path=${path} and year=${year}] to access an assessment about a specific path in a specific year.
  • The 5-year assessment analysis would likely be done on data from the path_assessment Entity List and the corresponding submissions could be ignored. In contrast, ongoing maintenance data would probably be accessed from submissions. You can mix and match as appropriate, keeping in mind that once an Entity is created from a Submission, the two lead separate existences (updating one doesn't update the other).
  • One limitation/downside to consider is that currently a form submission can only update one Entity List. That means if the assessment creates an Entity in the path_assessment list, it can't also update a path Entity to do something like mark the Entity as visited in the current year. Instead, you have to write more complex expressions to compute things like completed status.

Hopefully these high-level notes are helpful to someone. I'd like to eventually put together a worked example for this. @seewhy is there any chance that your data is or could be made public? It would be very cool to build a demo for some real paths that people could potentially go visit. No pressure, though, I can always generate data!