Settings and activity
13 results found
-
19 votes
Zach Ehmann
supported this idea
·
-
8 votesZach Ehmann
shared this idea
·
-
42 votes
An error occurred while saving the comment Zach Ehmann
supported this idea
·
-
15 votes
Thank you for your feedback. We are currently reviewing this request.
Zach Ehmann
supported this idea
·
-
22 votesZach Ehmann
supported this idea
·
-
12 votes
Thank you for your feedback. We are currently reviewing this request.
Zach Ehmann
supported this idea
·
-
41 votes
Thank you for your feedback. We are currently reviewing this request.
Zach Ehmann
supported this idea
·
-
14 votesZach Ehmann
supported this idea
·
-
16 votes
Thank you for your feedback. We are currently reviewing this request.
Zach Ehmann
supported this idea
·
-
5 votes
Thank you for your feedback. We are currently reviewing this request.
Zach Ehmann
supported this idea
·
-
38 votes
Thank you for your feedback. We are currently reviewing this request.
Zach Ehmann
supported this idea
·
An error occurred while saving the comment Zach Ehmann
commented
San Luis Obispo CoC is also looking for this functionality. Ideally would have at least two markers: one that calculates based on the assessment date and another that calculates as of the exit date (substituting current date if exit is null).
-
2 votesZach Ehmann
shared this idea
·
-
2 votesZach Ehmann
shared this idea
·
I very much support this request. My sense is that it entails a number of more specific requirements and use cases. Here are the two main ones that brought me here:
1. In building Looker reports, I want to be sure I understand the behavior of derived tables and related filters, dimensions, and measures. In my mind, this requires knowledge of which Clarity fields are being referenced, the LookML object type/derivation method, and the overall table structure of the given Looker model -- as all of these impact how the derived table interacts with the Looker filter context. My hope is that having access to the LookerML or SQL definitions of the derived tables would provide some insight into these factors.
2. Our community has access to the Looker SQL model. I very much appreciate the existing documentation (help article [https://help.bitfocus.com/customer-sql-data-model] and gitlab repository [https://gitlab.com/bitfocus-public/clarity_custom_sql_model]) and would like to see these updated and expanded. For the gitlab repo, specifically, I would like to see an update to reflect the 2024 HMIS Data Standards, a folder that contains SQL definitions for all tables, and more comprehensive documentation on how the tables are related with the consideration of an audience that's likely most familiar with HMIS HUD CSV structure [https://files.hudexchange.info/resources/documents/HMIS-CSV-Format-Specifications-2024.pdf]. Some of the sample queries presented in the gitlab repo already include table definition and have comments that indicate the mapping to HMIS elements, which is helpful!