Query Validation was a very good hint!

The code is the actual invite_code generated by CB Invites. The user is not supposed to reenter this code during the registration process as the invite_code field gets automatically populated with the parameter taken from the url. An invite_code's expiry date is stored in a private db table.

I published the invite_code field to the registration form as it seems to be mandatory for the registration process. Sadly, it seems that Query Validation does not have any effect on the invite_code typed field?

That's why I added a new textfield to manually enter the very same invite_code. For this custom field the Query Validation works very well.

So, overall Query Validation would help me to reject a registration attempt with an invite code that has been expired. However I'm not satisfied with the options I have figured out so far.

- If I can not add a Query Validation to the invite_code field I do not like to have the user copy the same code to another custom input field just for the validation.

- If I could have just this custom input field I would like to get the content populated either from the url or from the real invite_code field. Not sure whether it is really mandatory to publish the invite_code field on the registration form to successfully complete the process?

- Lastly, is there an option to make a required field read only on the registration form?

I would be happy with a non-editable field that holds the CB Invites generated invite_code that would allow me to Query validate the code against my private expiry date table when the user hits the submit button. Hope you have further suggestions!

Nice, but I'm not quite sure whether this implementation helps me.

Guess this new "Expiration Timeframe" is a system setting that's been added to all invites' "sent" timestamp at registration time since I cannot find a new column in the jom_comprofiler_plugin_invites table that would hold an individually calculated expiration date.

My use case requires an absolute expiration date: All sent invites are valid till an event the user has been invited to starts. So, the closer to an event's startdate the invite has been sent, the shorter the remaining expiry timeframe. With a system wide "Expiration Timeframe" of 1 DAY, say, an invite would get invalidated too late if an user has been invited hours before the event kicks off.

The "Event_Startdate" varies across different events users can get invited to in parallel. For my solution I have AAed the calculation of the expiry date, stored it in a private table and would like to validate against it at registration time.

If an "invite code" typed field does not allow for a custom query validation (why not?) I see two more options:

1) Add an "absolute expiry date" field to the jom_comprofiler_plugin_invites table that gets validated by default if set and can get updated by an AA.

2) Allow for a more sophisticated php coded "Expiration Timeframe". Most likely the validation rule is "now() > sent + Expiration Timeframe". If one could substitute "Expiration Timeframe" with "Event_Startdate - sent" the rule would validate as needed. However, this would bring this validation very close to a standard query / code validation, which I would prefer.