This proposal suggests enhancing our duplicate checking logic for specific protection profiles to balance hijack protection and reduce duplicate profiles. Currently, it is recommended to disable duplicate checking is disabled for Medium, High, and Extreme protection profiles to bolster hijack protection. However, this approach can result in an increased number of duplicates, especially considering more active individuals typically fall in more protected categories.To address this, we propose a two-tiered approach: Continued Evaluation for Low Protection Profiles: Individuals with Low Protection profiles would undergo duplicate checking using the existing logic. Additional Checks for Medium, High, and Extreme Protection Profiles: For individuals...

---

Currently, the block settings for the account entry block don't allow admins to choose which campuses are available for users to choose from (all or nothing). It would be great if we could filter out campuses, depending on their type & status. 

---

First, the impetus of this Idea was born out of the frustration of seeing changes to all of the (multiple) Giving-Analytics-related Person Attributes completely cluttering up Person History. This happens because the Giving Analytics process is just storing its data in regular old Person Attributes (perfectly fine), and today, any changes to a Person Attribute get recorded as  "Demographic Changes"  in Person History. These entries can overwhelm the other Demographic Changes that we are ACTUALLY looking for.Here's an example of these attribute changes:And here's a short screen cap that shows how distracting and cluttered these attribute changes are, because there...

---

On the "Edit Family" block, many (most?) churches do not use the "Family Status" drop-down. It's not mentioned in the documentation at all. It's also one of the few attributes in that block that can't be hidden. I can hide Campus, Birthdate, Title, Grade, Age, and County, but I can't hide that.I think most churches would benefit from it being off by default, but I'd settle for the option (in the block properties) to hide this particular box.Note: This is somewhat similar to Idea #1274, which I voted for, but it's a much smaller and more targeted change.

---

Hello! The autoplay option for YouTube Lava ShortCode will not work without `&mute=1`. Please update the code. Thanks!

---

In our constant attempt to convince our staff to use Rock forms instead of Google forms, I often find myself needing to convert a previously-used Google form to Rock. One of the most difficult pieces to replicate is the "Other" functionality that lets users enter an alternate value directly in the selection field. The current best way to do this is to use a single/multi-select and then a conditional text field to capture the "other" option. My proposal would be to add a "Include Other" checkbox to the single and multi-select configuration. When selected, it would add an "Other" option...

---

It would be a nice enhancement to the job: Send Group Attendance Reminders  to be able to send reminders based on groups in a data view. There are churches that do this now with a custom job but would like to have it added to the core job above so that we can use other functionality such as Attendance Reminder Start Offset Minutes. (an effort to not clone and customize core functionality) Imagine being able to send attendance reminders but limit some groups that should not or would like not to get reminders. 

---

The web Prayer Block has long supported prayer request attributes to enable tracking additional information about prayer requests. If these attributes are marked Public and All Users are given Edit access, the attributes show up as data fields on the web block.The mobile Prayer Block does not appear to support these attributes. This forces us to redirect users from the mobile app to a web page.We would like to see prayer request attributes supported by the mobile block.

---

Imagine a world where you can control what fees are available based on registrant attribute answers, or registrant attributes based on what fees are selected, OR make fees conditional on other fees!For example, imagine you have a $250 fee that allows you to sponsor bags at an event. But only when this fee is selected should the question be asked, "Do you want us to handle ordering the bags, or will you?" With the new Obsidian block, we can't use Javascript to hide/reveal registrant attributes based on other things selected on the page. And, honestly, that was never a great...

---

I added a dummy button in HTML below the Communication List Block as many members were wondering if indeed, they did subscribe when they checked off a particular communication list they wanted to be added to. People are used to having to hit a 'subscribe' button when joining an email list. I'd like to request this be part of the comm list subscribe block. Here's how I've set it up with some HTML and Javascript, but it's all for show :). https://share.zight.com/6quXjPvg

---