Nigel,
Thank you! This worked, and the logic was simple to implement in my place.
Perhaps a feature to not require this custom code might be a nice add?
Regardless, thank you as always!
Cheers,
Mark
Generic Fields are not persisting to the post, so we cannot use them to send notifications, even if those are sent after (even if slightly after) the form is submitted.
The solution to this is either use Fields that persist (created in Types) or, to use Custom Code that grabs the generic field and uses that in the notification, but that usually as well implements storing that value somewhere, for technical reasons, since the notifications are sent after the form is submitted in all cases and the $_POST (where such generic data is still present) is gone at that moment.
To change that is not easy, it's not possible, without storing the field value somewhere, even if deleting it after again.
So the real issue here would be, it seems, you want to use data that is not present when a notification is sent, in a notification, or for a notification.
That would require a whole new approach of how to save, and if to remove later, the Fields's value, as without saving it, we will not be able to trick out the machines and make them do something if there is nothing they can read 😉
Can you elaborate how exactly it would help you to have a Generic Field determining a notification?
I assume this is related to privacy, as otherwise there is not much reason to use generic (not persisting) Fields?
Sure -- I am using forms to allow administrators to approve posts (think a directory site whereby new listings / updated listings are first approved by admin before showing publicly). I am using this to allow the admin to choose if the member will receive an email notification of the approval / decline.
And what is the reason to not persist in this field?
I gather the admin will edit a post with the form and the generic field would then trigger the notification, since that is not possible, and it does not seem you have a privacy reason to not save that information (which can be anonymous, like "1", or any other value), I'd suggest using a native Toolset Types Field, which persists, and which you can use for this.
The request to allow this would require to persist the generic fields since notifications are sent later than when the form is submitted (a little) to leave space for validation.
Would that help?
Sure, I could do that, but this field is not something that should stick/persist with the post ultimately. I understand it could, and this would work, but then we have to deal with hiding an exposed field in the admin panel.
Either way, just a suggestion, and I find value in it. To me this seems like a shortcoming from the UI perspective, seeing as there are a number of other options already available for CRED notifications, but the implementation here works fine for my case.
Cheers,
Mark
Thank you, Mark.
I suggest you would submit this idea here:
https://toolset.com/home/contact-us/suggest-a-new-feature-for-toolset/
We just changed how feature requests are gathered, and there you will be able to add this suggestion, so Product Management can consider this directly.
Thank you!
