Electronic Document Sharing
In controlled access areas of the web site, section members share electronic
documents. Report and searching by file type, content, title,
abstract, provider, date and size. Links to online member database to
keep provider information current.
The largest, completely new development project that I had on ATLA NET
was the development of Document Libraries, an electronic document
sharing solution for ATLA's Sections. The purpose was to provide
an easy to use web application that would let members of a Section
share electronic legal documents with their colleagues. It included
upload, reporting, search and download capabilities for electronic
Like all dynamic ATLA NET web pages the document library pages were
tied into the standard table driven security front end. To use the
document library ATLA members had to belong to both the specific
section and be a voting member. Much later the restrictions were
relaxed. If the member was qualified by virtue of their memberships,
they also had to agree to an online contract (described in the
next page). The original implementation
had very different agreements for uploading and downloading. ATLA's
General Counsel prepared the final wording from drafts I wrote.
The electronic libraries were a major impetus for the more general
online contract system.
Users who met the security requirements and agreed to the online
contract would first see a standard report form showing documents
already in the library. The default report format showed the document
title (which could be fairly long), the document legal type such as
brief, deposition, memorandum, letter, pleading, etc. the date the
document was uploaded and a link to a details page. The default sort order
was reverse upload order so a user could check their section libraries
from time to time and see all the new documents at a glance. The
anticipation was that this would be a moderate to low volume application,
at least initially.
By simply adding or removing check marks from HTLM form check boxes
the user could include any or all of eight columns in the report
format. They were title, abstract, legal document type, file format,
filename, upload date, the name of the member who uploaded the document
and the file size in bytes. The user could use a radio button to select
the sort order from title, legal document type, file format, file name,
upload date or uploader's name. There were also filters to limit
results. Drop down selections would limit legal document type, file
type and / or upload date ranges of displayed results.
Uploader and file name could be selected by a wild carded string match.
The instructions described a more or less standard string match using
an asterisk as a wild card character. Actually if the user entered one
or more asterisks without other preceding special characters, the
asterisk was turned into a period and asterisk and the result evaluated
as a regular expression. If the user actually entered a period and
asterisk or other regular expressions these were evaluated directly.
The "more" link that was automatically included in all report formats
lead to a single page that included all 8 fields that were available.
This page was dynamically generated from a database containing user
entered and calculated fields. When a document was uploaded, the same
data that was saved into the database and used for sorting, selecting
and formatting the reports as well as creating the dynamic "more" page, was
also written to a static HTML page that almost exactly duplicated
the dynamic "more" page appearance.
Because Microsoft's Index Server was already in use, we wanted to take maximum
advantage of it. While it will index WordPerfect and other binary
documents that contain ASCII strings, the displayed results are less
than pretty. The static version of the "more" page was solely for
Index Server. The system contained no links to these static pages which
would only ever be presented to a user from Index Server results pages.
If the document uploader entered good titles and abstracts
that would make documents relatively easy to find via Index Server.
In practice a
number of users actually took to pasting the entire document contents
into the abstract field which had the effect of making it full text
searchable. The uploaded documents could be in any file format
and this format was preserved. The extra static "more" page provided
reasonable searching capabilities regardless of what the file format
of the uploaded document.
When a user uploaded a document, they were prompted for five pieces
of information including the upload file name. All were requried.
The path was striped out but the file name retained and used as the
actual saved filename. The matching static document used the same
name plus ".htm". For the legal document type and file type, the user
selected from a drop down. If they chose "other", the other descriptive
field was required. The plan was to use these over time to add new
types to the drop down selection as patterns were detected. Title
and abstract were required but except for requiring some content
the system could do nothing force meaningful content. Uploaders
were generally quite conscientious about these fields.
The original uploader could correct or update any of the information
that they supplied when they originally uploaded a document at any
time in the future. If the uploader ever viewed the dynamic "more"
page an update button would appear that no other user saw. This
button lead to an editing page that had all the user entered data
and included a preview page. While uploaders could correct
any data they supplied, they could not delete an uploaded document
and no one could upload any new document over an existing one. If
they could, then documents could be effectively deleted by uploading
an empty document over an existing one. If there was a valid reason
for removing a document from a document library this function had to
be performed by an ATLA staff document library administrator.
The dynamic "more" page also included
a delete button if the user was a document library administrator.
The static page had both update and delete buttons but the invoked
programs checked that the current user was the correct user before
allowing these function to be performed.
The system determined the upload date, file size and the uploader's
name from the AUTHENTICATED_USER value. On the "more" detail page or when
user selected it for inclusion in the report format, the uploader's
name was displayed but no other information. Their name was a link to
a one record query into the member directory so that current contact
information would always be available. The link was based on an
encrypted version of their member number.
As part of the document library project, the standard search form
was enhanced to include search the current section area, search all
sections or search the entire site. A key strength of Microsoft's
Index Server was that in a search like this if the user selected
all sections but was only eligible (had the necessary OS file
rights) to see results from say three,
those would be the only ones Index Server would return. Each document
library was associated with its own NT group and section members who
qualified were automatically added to this group during registration
or by the nightly update processes. No programing or configuration
had to be performed to cause Index Server limit the displayed result
list. If the user did not have the rights to retrieve the document
Index Server would not reveal that it existed.
Top of Page -
Copyright © 2000 - 2012 by George Shaffer. This material may be
distributed only subject to the terms and conditions set forth in
These terms are subject to change. Distribution is subject to
the current terms, or at the choice of the distributor, those
in an earlier, digitally signed electronic copy of
http://GeodSoft.com/terms.htm (or terms.pl) from the time of the distribution.
Distribution of substantively modified versions of GeodSoft content is
prohibited without the explicit written permission of George Shaffer.
Distribution of the work or derivatives of the work, in whole
or in part, for commercial purposes is prohibited unless prior
written permission is obtained from George Shaffer. Distribution in
accordance with these terms, for unrestricted and
uncompensated public access, non profit, or
internal company use is allowed.