That was fast with the smaller suggestens, thanks
As a quickfix for me only i modified the sql wich checks if the Poll is finisched that it looks for certain prefix ID's for the thread of the poll so it looks if the thread has certain prefixes (for the quickfix "accepted" or "denied" with other prefixes nothing happens).
Prefixes are also the best suggestion for this "flag" that i have. Moderators can change the flag and it mostly uses features that are already there.
As Example: our manual process with the application forms we had in vbulletin was the following:
1. The created thread gets the prefix "new"
2. The discussion on the application and the voting occurs
2a. If the applicant withdraws the application before the discussion reached an end -> the thread gets the prefix "withdrawn" -> the application is canceld
3. If the discussion reached a conclusion the thread gets the one of the two prefixes "accepted" or "declined" and the applicant gets the information mail.
For the automated process the following 2 versions should work :
1. The short and easy way
- You define a prefix for the thread when it is created (already there)
- You have a list of prefix ids (maybe 4,5 for accepted, declined) wich signal the the process is at an end the cron-job should take the poll as finished und process the results as if the poll would have reached the end of the defined timeframe.
- All other prefixes the thread has do not have any meaning for the process, the poll stays open.
- You define a prefix for the thread when it is created (already there)
- You define one prefixid wich stands for "canceled". In this case the poll is finished but no further action is taken, no pc's are send out.
- You define one prefixid wich stands for "accepted". In this case the poll is finished and the application is taken as "accepted" even if the voting says otherwise. The voting in this case is only to help in the process of the discussion to reach a conlusion.
- You define one prefixid wich stands for "declined". In this case the poll is finished and the application is taken as "declined" even if the voting says otherwise. The voting in this case is only to help in the process of the discussion to reach a conlusion.
My modified sql in the poll model class wich essentialy works like the "short and easy" way only with hardcoded thread ids:
Code:
SELECT
xf_snog_applications_polls.app_pollid AS app_pollid,
xf_snog_applications_polls.poll_id AS poll_id,
xf_snog_applications_polls.posid AS posid,
xf_snog_applications_polls.user_id AS user_id,
xf_snog_applications_polls.promote_type AS promote_type,
xf_snog_applications_polls.pollpromote AS pollpromote,
xf_snog_applications_polls.poll_enddate AS poll_enddate,
xf_snog_applications_polls.poll_reverse AS poll_reverse,
xf_snog_applications_polls.orig_group AS orig_group,
xf_snog_applications_polls.orig_additional AS orig_additional
FROM xf_snog_applications_polls
JOIN xf_poll ON xf_poll.poll_id = xf_snog_applications_polls.poll_id
JOIN xf_thread ON xf_poll.content_id = xf_thread.thread_id
WHERE
xf_thread.prefix_id =3 OR xf_thread.prefix_id =7'
(yes that happens more often than one would think).
