One concern administrators have about a content management system is the potential for abuse. If someone manages to access the form that enables users to add a new Traveler's Journal for malicious purposes, you want to know who did it. Or, more specifically, you want to know whose account was used to do it. That way, you can identify the responsible employee (if it was an employee) or at least remove the account (if it was not). In this task, you'll capture the account used to access the admin pages, and save it with the accompanying journal_entry.
The technique you will useand this is explained in more detail as you do itis to capture the user's identification as it is stored in a session variable, and copy that value into the form using a hidden field. The contents of the hidden field will be submitted with the contents of the text area, and stored in the database.
In admin_update_tj.asp, insert a hidden field just to the left of the Submit button. Name it author.
This hidden field will store the name of the account used to access the page. At this stage, though, it has no value, because you haven't bound any data to it.
The question is, how do we find out whose account has been used? To answer that, think about what data is available to the page. This page has a Restrict Access to Page behavior attached to it. This behavior checks for the presence of a session variable set when the user successfully logged in. If that variable exists, it checks to see if its user is in the admin group. In other words, for a user to be on this page, she or he must not only be logged in with an admin account, but also the page must already know which account. Since this information is already available to the page as a session variable, all you have to do is bind that value to the hidden field, and it will be written into the database along with the form.
Use the Bindings panel to add a new session variable binding. In the Session Variable dialog, enter MM_Username, and click OK.
MM_Username is the session variable that is set when the user logs in. It is created automatically when you use the Log In User server behavior.
One thing to remember about the Bindings panel: The bindings it lists are limited to ones that you enter. In other words, even though MM_Username has been available all along as a session variable, as a part of the Restrict Access to Page server behavior, it is not listed in the Bindings panel unless you explicitly put it there.
Select the hidden field, if necessary, then select Session > MM_Username in the Bindings panel, and click Bind.
This binds the value of MM_Username (that is, the account name used for this session's log-in) to the hidden field. You now submit the author data along with the journal entry itself.