I hope that your non-preview version has some kind of access control, and user roles with limited privileges. For example no normal user should be allowed to delete another user's request.

I also don't know if it's wise to actually delete RFIs, they sound like a good documentation. Maybe archive them instead, and offer some kind of archive search?

The start page is a bit empty, you should put up some text there. And IMHO the navigation links are much too small, chose a larger font size here.

1)Absolutely, the admin will be able to grant permission at different levels depending on the user and his need to know function.

2)Correct again, all RFI's will be archived or marked so that only the admin can retreive archived or "deleted" rfi's.

3) I am waiting for my wife to design the graphics and fill up the front page with neat buttons and related information.

Each RFI accound would be independant of another though the admin would be able to get a "bird's" eye view of the entire scope of CA activity that the firm is involved in, arent databases wonderfull?

In addition to moritz's fine points...

• Really consider your security / data sharing model. Contracting can be very competitive, IIRC, sharing information between a general and a contractor is very different from sharing information between a contractor and another contractor. Consider carefully the trust relationships that you permit by default. Security is much easier to design in up front than it is to bolt on after the fact.
• I am assuming that some contractors submitting RFIs may be competing against each other: if this is the case, then I would stress moritz's point even stronger - one contractor should not be able to see another contractor's information, unless it has been explicitly made public (or public to a specific role).
• Is there a way to limit display to only a single project, or would there be a per-project installation on this? I could ask the same question about phases of a project.
• Your header and data halves of the table do not seem to line up. This could lead to confusion for the user. Just looked at the code for the page. You have the two halves as two separate tables, and the widths don't even match up. Even if the widths do match up, depending on some of your wrap / clip settings, you may end up having them misaligned unless you make them both a single table.

These are just a couple of things off the top of my head. Experience: many years working for an electrical engineer, not doing any of the project work (other than drafting), but hearing many things, and 15ish years in the computer industry, most of them requiring thinking paranoid from a security perspective :).

1) As mentioned above the admin will full control of who sees what and so on.

2) This is as you put it very common and the admin will have full control when he creates a sub or a general contractor entry. Some general contractors who have alread been hired will be able to enter their own info there by freeing up the admin from having to do everything. The program will also send email to all who the admin has designated.

3) One of the most attractive features will be the ability of the admin or inspector to take digital pictures of conditions in the field and send them directly to the application there by letting everyone concerned to see the problem almost real time. NOt sure how I am goiing to do that but I am sure it is possible.

4)The entire suite would allow for seperate management of projects keeping them seperated.

DBD::mysql::st execute failed: Duplicate entry '010' for key 1 at init
+iate_rfi_send.pl line 173.
[download]

(Just a thought: in terms of reporting ID numbers of requests for use by people who submit requests: you might want something in addition to just an autoincrement numeric key -- e.g. prefix the number with the submitter's initials (or company initials, or some other short letter string), such that two different submitters (or submitters from different companies) get different letters, which are derivable from some other field in the entry for each RFI. This may help identify and sort out problems when people make mistakes like transposing, skipping, adding or changing digits in the numeric ID.)

I noticed that you ask the person submitting the RFI to fill in the "Creation date"; shouldn't that be set automatically upon submission? (ie. the table field for "creation_date" is set to the return value of "NOW()" when the insert is done). You also ask for a "PCR number if any" -- how sure are you that users know what this is?

Finally, you probably have some of this on hand or in mind already, but obviously the RFI submitter will want clear feedback on when to expect a response, how that response will be conveyed, who to contact if the response doesn't arrive as expected, and how to contact that person.

People charged with responding to RFI's will of course need a "response" table that allows them to submit entries reflecting phone conversations, independent email and IM dialogs, and maybe even office visits, in addition to internet transactions. (And requesters should be able to review all response records for a given RFI that they submitted.)

1) this one of the tweaking tasks that I need to refine. I am still trying to asses if the user needs to know the next number before or after completing the form.

2)good suggestion.

3)Yes the creation date will be automatic. Some companies have internal ways of keeping RFI's that they have. The PCR(I cant remeber what PCRstands for but it is meant to give the sub a choice if he keeds his own records) number will let them reference back to their system. Some contractors may not have computer based filing methods.

4)The feed back will usually be based on the way the contract is set up between the developer and the architect. Some contractors may have negotiated different responce times, but it may be a policy that a responce time be entered in the text message. The responce will be emailed to any one the responder feels needs to get the responce, the admin gets all responces and may add forwarding to any one ledft out. The program will also log when some one reads the responce, or at least opens that page. Whether they read it or not is a different matter all together but at least the admin can present a report that the responce was received.

MY thought is that the agreement between the architect and all parties involved must communicated via the RFI, but you are right there should be an additional log of none system communications.

Requesters will have access only to RFI's that concern them or their trade or as given permission by the admin.

MY goal is to give the admin full and total control of the RFI process and storage. He will be able to create reports on the fly at meetings rather than waite till he gets back to the office. If he has internet connection he can answer any question concerning the project at any meetings.This goes for all the subs, they will be able to report from the same database any info strictly pertaining to them.