DescriptionWhen a child is checked in, Rock should record which adult brought them, not just which family's phone number or child name entered. This would be stored on the attendance record (Checked In By Person Alias Id for example) and visible to room volunteers and ministry leaders. Details Right now, check-in tells us a child attended. It doesn't tell us who walked them through the door. The idea is fairly straightforward: During check-in, the attendant selects or confirms which adult is present That person gets stored as a "Checked In By" field on the child's attendance record Room volunteers can...

---

When editing a Lava Shortcode, the edit form action toolbar is only Save and Cancel. When Saving, it will close the editor and you have to click twice before getting back into the editor. It is annoying when you are working on a shortcode that you have to test, edit, test, and edit. Going back and forth and clicking twice to get to the editor is not a good UI/UX unless you remember the Lava Shortcode Id and enter it in the URL but that's a bad UI. It is more annoying now with v18.x where after saving, it resets...

---

It would be really great if known relationships were included when doing a post-filter transformation on a data view. More details can be found on the bug request I originally made: https://github.com/SparkDevNetwork/Rock/issues/6736Example: if someone is a known relationship (parent type), they do not show up when doing a post-filter transformation (parents) on a data view

---

When a plugin includes a migration to add a core block, and that block get's "chopped" with a new obsidian block, the plugin's migration will fail to run (it gets an exception for missing block guid). This requires plugin developers to release a new version of their plugin anytime a new version of Rock is released. This especially affects a theme plugin that has migration to add a lot of public pages using a lot of core blocks. wouldn't it be an easy update to the AddBlock() migration helper method to add try/catch and if an exception occurs, check the block...

---

Many times when Duplicate Finder suggests possible duplicates, I need someone to call or follow up with them more directly - for example to figure out which email address they actually want to use. We have a "Data Integrity" connection opportunity where we create requests to follow up on these, but it takes a lot of steps to create these requests.I would like to add a Custom Grid Action to the grid on the "Duplicate Detail" page, where the possible duplicates for a record are shown. I intend to have the button create a connection request in the correct opportunity...

---

Giving Alerts is a great and powerful feature.  It would be better if Giving Alerts supported First Time Donor as an actionable alert.  This would allow us to trigger a connection request and encourage the congregant.  We currently have this implemented outside of Giving Alerts due to this limitation but that is a custom process that we would like to get rid of.

---

We think it would be a good idea to have Rock automatically add ~JSB to a check-in label ZPL when a cutter is in use (meaning, the client is set for "Enable Label Cutting" or the Printer Device in Rock has "Has Cutter" enabled.The problem being solved is this: The default labels in Rock use ~JSN, which tells the printer to backfeed AFTER a label has printed, which is great for non-cutting printers, but on a printer WITH a cutter, ~JSN causes:The label prints, then the printer backfeeds and the next label rests on the rubber platenThis induces a curl...

---

Concise DescriptionIt would be helpful if it was possible to add a “Send Test” button to the pending communication approval page so approvers can send themselves a test version of the message without needing to open the communication in edit mode and step through the full communication creation process.Additional DetailsCurrently, when a communication reaches the approval stage, the approver only has the options to Approve, Deny, Edit, or Cancel. If they want to send a test to verify formatting, links, dynamic content, or dashboard rendering, they must click Edit and step through the entire communication setup process before accessing the...

---

Currently, the check-in system only allows individuals to check in to a group if they have an Active member status, meaning anyone with a Pending status is excluded from the process.  We'd like to propose adding a setting at the Group Type level that gives administrators the choice to allow Pending members to check in alongside Active members.To further simplify the workflow, this optional setting could automatically move a Pending member to Active status upon their first successful check-in, reducing the administrative burden on group leaders. This approach is consistent with how the Group Attendance Entry block already offers a "Show Pending Members" toggle, and...

---

In Rock Mobile’s Connections tools, add a configuration setting that allows administrators to enforce “My Connection Requests” and “Only My Connections” at the block or security-role level. This would ensure that assigned connectors (such as volunteers) can only view Connection Requests explicitly assigned to them, without the option to toggle to view all open requests across all types.Currently, volunteers with access to the Connections block can switch filters and see all open requests, even if they are only responsible for their own assignments. While the web experience supports structured workflows and connector filtering , the mobile experience lacks an enforcement...

---