An optional drawing must not make a quotation request disappear

An enquiry form can honestly describe a drawing as optional while the office screen behaves as if every request must have one. The visitor sends a valid description, receives an acknowledgement and waits. Staff never sees the request because the list was built from the documents table instead of the requests that need attention.

This is a fictional industrial quotation example. It concerns the relationship between an enquiry and an attachment, not a recommendation to add public uploads to this site's contact form. File handling needs a separately agreed security and data-handling scope.

Establish the intended population

Three enquiries arrive. PL-801 has an approved drawing attached. PL-802 contains enough written information for an initial discussion and has no drawing. PL-803 includes a file that is still awaiting the designated handling checks. Under the example business rule, all three requests belong in the initial review queue.

The file's status changes what staff can open or ask next. It does not decide whether the enquiry exists. A list containing only PL-801 is therefore incomplete even if every displayed row is correct. Counting files would not expose the missing population because two requests have no usable document at that moment.

Write the expected list before changing the query: three request identities, with separate attachment explanations. The business owner should approve this rule. A different organisation may require a document at a later technical stage, but that requirement should be represented as a stage decision, not hidden in an accidental reporting filter.

Find the point where absence becomes exclusion

A developer may discover an inner join between requests and attachments. Such a join retains rows with matching records; a request with no attachment can fall out. Replacing it with a left join can preserve the parent request, but a later condition requiring an attachment status may remove that same row again.

The important question is what each condition means. Is the page listing all enquiries needing initial review, or only documents that are ready to open? Those are different views. Both may be useful, but their titles, counts and expected members should be distinct.

Several attachments introduce another problem. PL-801 might appear twice if two documents match. The queue still represents one request. Its document section can list two files without duplicating the work item or making the headline total appear to be four requests.

Give staff a truthful next action

For PL-802, the interface can show that no drawing was supplied and let the reviewer decide whether the written information is sufficient. It should not label the request “upload failed”; no upload was attempted. For PL-803, the file can remain unavailable while its handling checks are pending, with an authorised owner responsible for the next step.

A requested replacement drawing is another event. Staff should be able to associate the later file with PL-802 without changing the original submission history into a claim that the drawing arrived with the first request. The business decides which version is suitable for assessment and who may view it.

These distinctions help the customer-facing explanation too. “Request received” is not “drawing approved” or “quotation accepted”. The acknowledgement should use the milestone the system can establish.

Test the set, not just one successful row

Create a private fixture containing a request without a file, one with a pending file, one with an accepted file and one with two files. Compare the displayed request identities with the expected set. Inspect the detail view and check the count separately. Then change a document's status and verify that the request remains visible wherever the stated queue rule requires it.

Include permissions. A reviewer who cannot open a restricted document may still need to know that a request requires an authorised colleague's attention. Showing a confidential filename to every role may itself be an unwanted disclosure, so the appropriate explanation must be agreed.

An application can successfully store an enquiry and still fail the receiving team. Business application development should therefore include the queue's intended population and the actions staff can take. PostgreSQL's table-expression documentation explains the underlying join behaviour; the organisation supplies the business rule that the query must express.