CoreX v0.45.2

Two changes on top of v0.45.1, both for a form defined in code.

A form's notification email names the file it was sent with and links to the submission. The email printed the number the file is stored under. It prints the file's name, and a line under the answers links to the submission in the inbox, where whoever may read it opens the file. The file is not attached.

The inbox's search finds a submission by the sender its row shows. A search for the name or the email shown in a row answered "0 accessible submissions" for every form defined in code.

Nothing to set and nothing to rebuild. Read Client impact if a site writes its own notification emails: CoreX's email is not the one such a site sends, and its listener is handed what it needs to add the same link. A search does more work than it did; the measure is below.

Changed

• A form's notification email names the file it was sent with, and links to the submission (spec 081, Phase G; DECISIONS #319). The email printed the number the file is stored under ("Cv: 224"). It prints the file's name, and under the answers a line says the file is opened from the submission, after signing in to the site, with a link that opens the Submissions inbox on that submission. The file is not attached: that is the owner's decision, because a file sent to a mailbox cannot be taken back, and the inbox gives it only to whoever may read the submission. An email of a submission with no file is as it was.

Added

• A form's listener can point at the stored submission. FormSubmittedEvent::submissionId() is the id of the submission, once the listener that stores it has run, and Corex\Mail\SubmissionAddress::of($id) is where it is read in the admin. Corex\Forms\Submission\UploadedFileNames::in($slug, $values) gives the name of each file sent with a form.

Fixed

• The inbox's search finds a submission by the sender its row shows (spec 103, T110 to T113; DECISIONS #318). A submission of a form defined in code showed its sender's name and email in the row, and a search for either answered "0 accessible submissions": the search read two fields only a flow's submission has. It now looks where the row reads the sender, in the answers named name, full_name, first_name, email and email_address. The search on CoreX → Data → Form submissions is the same one and finds them too. It does not look in the other answers.

Client impact

• A site that writes its own notification emails (a form that lists its own listener) is not changed by this: CoreX's email is not the one it sends. To link its own email to the submission, list StoreSubmissionListener before its listener, read $event->submissionId(), and ask the container for Corex\Mail\SubmissionAddress. $event->values still holds a file as the number it is stored under.
• A routed email template that prints a file's answer (submission.<field>) prints the file's name where it printed that number. The address is in the context as submission_url.
• Nothing to rebuild: no script or stylesheet changed.
• The search finds submissions already stored: nothing is written to them, and there is nothing to run. A form whose name or email question has another name than the five above shows no sender in its row, and is found by its form.
• A search does more work than it did, because it now reads the senders of forms defined in code, which it used to pass over. Measured on 10,000 submissions, the search's statement took about a third of a second where it took a tenth; that is still less than listing the inbox with no search (DECISIONS #318). It was not measured on a smaller site.