SVERIGE 2012

CONFIDENTIAL

Errand and Document Handling System

Version: Date: Author: Document Responsible: Department: File Name: Approved by: Signature / Date:

2 20120223 Jens Hedin, Johannes Hkansson Jens Hedin, Johannes Hkansson

Dirty Harry

Version: A Date: 2012-01-01

Implementation Specification

Page 1 (31)

 SVERIGE 2012

Document History
Version 1 Date 12-01-20 Description First version Comments/clarifications after review. We have marked all the new areas in color green. Author Jens Hedin Johannes Hkansson Jens Hedin Johannes Hkansson

2012-03-22

Distribution List
Name ByteAnt Department

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 2 (31)

 SVERIGE 2012

Contents
1 GENERAL...............................................................................................................................................................................4 1.1 SCOPE...........................................................................................................................................................................4 1.2 ADDITIONAL INFORMATION...............................................................................................................................................4 2 SUGGESTED DB LAYOUT.................................................................................................................................................5 3 USER ROLES/ACCESSLEVELS........................................................................................................................................7 3.1 HIGH ACCESS ...............................................................................................................................................................7 3.2 MEDIUM ACCESS ...........................................................................................................................................................8 3.3 LOW ACCESS ................................................................................................................................................................8 4 SYSTEM ADMINISTRATION............................................................................................................................................9 4.1.1 Util program......................................................................................................................................................11 5 WEB APPLICATION .........................................................................................................................................................11 5.1 GENERAL.....................................................................................................................................................................11 5.2 MENU SYSTEM.............................................................................................................................................................12 5.3 UPLOAD PAGE..............................................................................................................................................................12 5.4 DIFFERENT HANDLING/PROCESSING TYPES.........................................................................................................................13 5.4.1 Archive document..............................................................................................................................................14 5.4.2 Delete document ...............................................................................................................................................14 5.4.3 Redefine document ...........................................................................................................................................15 5.4.4 Pop document ...................................................................................................................................................15 5.5 THE QUEUE AND ERRANDHANDLING................................................................................................................................15 5.5.1 Choosing division and group.............................................................................................................................16 5.5.2 Listing the queue...............................................................................................................................................16 5.5.3 Detailed view of errands (for each doctype)......................................................................................................18 5.5.4 Processing a document .....................................................................................................................................19 5.5.5 What should happen when the user has processed or handeled a document?..................................................20 5.5.6 Archiving ..........................................................................................................................................................21 5.5.7 Pop functionality...............................................................................................................................................21 5.5.8 Redefining.........................................................................................................................................................23 5.6 ARCHIVE SEARCH PAGE DIALOG.......................................................................................................................................24 5.6.1 Searchable fields archive..................................................................................................................................24 5.6.2 fields Displayed in grid , archive.......................................................................................................................24 5.6.3 Date function.....................................................................................................................................................24 5.6.4 Detailed view in archive archive.......................................................................................................................25 5.7 DOCUMENT INFO AND DOCUMENT NOTE AND DOCUMENT LOG.........................................................................................25 5.8 OPENING A DOCUMENT .................................................................................................................................................27 6 FUNCTION/PROCESS DESCRIPTION..........................................................................................................................27 6.1 DOCUMENT STATUS.......................................................................................................................................................27 6.2 USE OF DYNAMIC ARCHIVE FIELDS..................................................................................................................................28 7 UTIL PROGRAM OUT OF SCOPE.................................................................................................................................29 7.1 DOCUMENTRESETTER FUNCTIONALITY...............................................................................................................................29 7.2 DELETE OLD ERRANDS...................................................................................................................................................30

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 3 (31)

 SVERIGE 2012

GENERAL

This document describes an errand/document handling system. The errand handling is how the operators pick the errands from the queue, processing them and returning them to the system again, during this process the errand move between different statuses.

A documentsystem system is usually a system that handles documents in some way involving different versions of a document, checking in and out version etc. There is also often a status like under review or published connected to the document. A errandhandling system usually handles defects where some user reports some error or issue and another person receives this ticket and solves the defect. This system is a little bit of both these worlds and we believe there is a market for a small system like this for small to midrange companies.

1.1

Scope

This is the first version, the base functions are described. Future development will be needed. The gui handling is described.

1.2

Additional Information

GUI is referring to the web application. ADE is Add, remove, edit Errand and document is often used as terms in this document. The meaning is the same, and errand is a document and a document is an errand. Errandtype is the same as documenttype.

Dateformatting shall always be YYYY-MM-DD hh24:mi:ss

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 4 (31)

 SVERIGE 2012

SUGGESTED DB LAYOUT

This is the suggested db layout.

Its not a 100% accrate and should only work as a suggestion. Is based on a similar system that has worked for hundreds of users for many years. The normalization is vital if performance will be good in a system like this. We want clean simple relations between the tables. The entity names we also want to keep since we are familiar with these.

Few main issues or queuestions we see about wanted database structure: 1. Table Program and its usage with DocLog. It is not explained or mentioned in this document at all. Needs more info, what table Program is for.

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 5 (31)

 SVERIGE 2012

A program might be any external program that creates a document , update a status in the table and that creates any row in table doclog. For instance, the utility program resets an errand and also logs a row into the doclog table. The utility program will have an own id in table program and all rows that the utility program has worked with will have the utility-id. Since the utility program is not in scope, create the table but update the doclog table with some dummy data like 0 or null.

2. Table Docstore. As we see it, we can just omit using this table and store documents as physical files on disk. This should simplify development and save time. Is there any reason you would like to store actual files in database? All the fields you have designed for this table, that is their values, can be taken directly from files on disk.

We have discussed both these methods in and out but we have decided to stick with the blobstore. We realize both methods has their advantages. Later on we might develop filestore option but at this point we want to store the files as blobs in db. Benefits of db store It is more secure. We can log who read the document. Anyone with access to the server can read any document in filessystem. It is safer with backups. It might be a better option if you are gonna start working with versionhandling.

But. On the other hand. Require additional code to extract and stream the images Latency may be slower than direct file access Heavier load on the database server

3. We propose not to store passwords as they are for users so there was no possibility to get them, even with data stolen. See remarks below for access levels. Yes. We agree. The stored password should be encrypted. 4. We propose to add one more table for archive fields data. See corresponding section 8.

Yes. Looked at it and this is a good idea, but they dont need to be truly dynamically. Please see the comment under 8.1

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 6 (31)

 SVERIGE 2012

3
3.1

USER ROLES/ACCESSLEVELS
High Access

We have thought about the high user role, and with help from your queries we have come to a conclusion that this role is not needed. Our reason for having this role was basically to reset password, but that should be handled by the users themselves as you pointed out. We assume that you know how the resetting password can be solved best way (a crypted password will be mailed to the user?) and worst-case, if the user has wrong emailadress we(or db admin) can update the emailadress directly in db. From the systems point of view, there is only two roles:

Regular users (described as low access) . These users are users working with the errands on daily basis. Users with admin access (described as medium access). These users can manage the queues (medium access), but they also have low access and can work with errands in the queue as well.

This is the backend user. The user can create users, handling passwords, manage queues etc. Its the highest level of access in the system. New users will only be added by users with high role, is this correct? Or will they be able to register themselves too? Will there be any type of a) my account page for users to edit their info (including default division and group) b) forgot password to reset password themselves? What do you mean by handling passwords? Resetting them or assigning new one? Also as for passwords, I think there should be one way encryption used with salts. Not plain passwords in database... True. We should not store plain text passwords. Some encryption is needed. Its a very good idea to have a user-info page where the user can edit their own data. It should not be possible to delete users, because the users might have archived some documents. Resetting passwords should be possible. Maybe the passwords should be generated and sent through email as standard is today?

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 7 (31)

 SVERIGE 2012

3.2

Medium Access

This is the teamleading role as we see it. This user work with the queues. Opening, handling queues. Adding groups, documenttypes etc. Will there be any difference in what parts of data and how medium and high level access users manage queues and entities Division, Group and Document Type? Or will both high and medium access roles see exactly same pages for management of queues, divisions, groups and document types? With the changes described above where we have removed the requirement regarding high userrole this is not an issue any more. Just to clarify: the medium access role can do also have low access role.

3.3

Low Access

This is the regular user. This user works with the errands.

These users are users working with the errands but they cannot manage the queue. Managing the queues is: Add or edit a division, a group or a documenttype.

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 8 (31)

 SVERIGE 2012

SYSTEM ADMINISTRATION

This whole chapter has been rewritten since we dropped the high user role, hopefully it has become easier to understand. We have left you comment below in red but we changed in the menus since we realized its better to describe it all togheter instead of just one entity at the time.. Add, remove, edit = ADE The Team leaders with medium access role can add, remove and create groups, divisions and documenttypes (doctypes)

Should page to manage groups be somehow related with page to manage divisions? Asking because there is a relation between these tables. Will users have link on each division clicking which will show its groups and possibility to ADE? Or will page to manage groups just show all groups and on adding or editing dropdown with all divisions? Also, what should happen on deletion of a) division b) group? Should all related records be deleted auto? What if data is already present (related groups and links in groupbox)? Think we just forgot to include this. We suggest that this binding is done when you add/change the group. But you choose how you want to implement it. Easiest way is ok. It should follow the look and feel of the application in general. Updateable grid, perhaps? I see it like this:

One page where we can add/edit the divisons. Also deleting a division if we dont have any groups connected to that divison.

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 9 (31)

 SVERIGE 2012

One page where we can add/edit groups. In this dialog, when adding the user has to choose a division where the group is added. Should also be possible to delete the group if we dont have any documenttypes connected to that group.

One page where we can add/edit documenttypes. One page, called queue management where all the entities are tied together. In this dialog the user has to start by choosing a group. For the chosen group the documenttypes are listed. Here the user can close or open the queues by closing/opening the doucmenttypes for that group, thus creating a row in table groupbox. Maybe the best, easiest way is to have some searchfields for the division and group and then just listing the documenttypes in a grid, and in this grid we can open close the documenttypes? The searchfields should as a default option having All- and if the user only presses search or ok, all divison and groups are displayed.

As I understood one Group can be tied to many Document Types. On the contrary one Document Type to many Groups. GroupBox is table that holds these links. Please, correct me if no. From this point, as written above, you would like to have ability for medium and high level users to make these bindings. Could you give some details on how would that look from interface point of view? Would they click on a group on the page for group management and see all document types binded to it with possibility to add or delete? You named it close link. Is there any difference in meaning from delete link in database?

I think i mean that closing the groupbox is removing the link in db. It should not be possible to connect a already connected documenttype. It would be very good though if we can see in the gui to what groupbox that documenttype is connected to, like a message saying this documenttype is already connected to group: xx This is basically creating the connection between table group and documenttype -> groupbox. The groupbox will be the "queue" which is accessed by the regular users in the system(operator). Just to clear things up one queue is one record in GroupBox table, is this correct?

No. it can be several rows in groupbox. The queues are listed by chosing divison, group and then the queue is listed (showing several documenttypes). its the number of errands(documents) in each documenttype that is the queue together with the

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 10 (31)

 SVERIGE 2012

documenttype.. But you are sort of corrects also since each row in groupbox is part of the queue. The below section describing the default division and group.. we have decided to leave it out of SCOPE! Maybe we can still have the columns in the db Each user can have a default divsion and group assigned. This should not be mandatory. If no default group or division is set (on the user-info page) the user must select from a dropdown-box. On the contrary, if the user have a default divison and group these should be selected automatically.

44444

Util program

NOT in scope See also this chapter in the end of this document. Needs more info. This program should be possible to configure for this user role If we are going to develop this, it would be good to know what exactly do you want to configure on this page. What exactly values.

5 5.1

WEB APPLICATION General

The errand handling in the system consist of opening an errand, choosing handling type and then generally archiving the errand. Saying working with an errand is the same as "picking and errand". A documentsystem system is usually a system that handles documents in some way involving different versions of a document, checking in and out version etc. There is also often a status like under review or published connected to the document. A errandhandling system usually handles defects where some user reports some error or issue and another person receives this ticket and solves the defect.

This system is a little bit of both these worlds and we believe there is a market for a small system like this for small to mid range companies.

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 11 (31)

 SVERIGE 2012

5.2

Menu system

When a regular user logs into the system there should be menus Errend handling Where the user works with the errands Archive Where the user search for all types on errands/documents in the system. Upload page Where the user uploads documents to the system This page is not explained at all in the current requirements. Thus a lot of queuestions arise: How should the interface of this upload page look like? The User_id field of the Document table is its value assigned on a document upload? Does this field actually mean who uploaded a document? Or can value of this field be changed to other user in the process of work on it? Should there be on upload page dropdowns to select division, group and document type? Should there be possibility to add comments for new document on this upload page? Doc state should be n (new) after upload, correct? See next section 5.3. admin menus, both the admin menus might also be accessible. (not sure how these menus should be handled if the current user does not have acces to them...if they should should be visible or if they should not show at all. Obviously if the user does not have access to these functions they should be prompted to logon on with a different user...maybe a question should pop up..Do you want to log on as a different user?) As for your queuestion here it is up to you, but I guess it would be more logically correct to not show menu items to which a user does not have access.

5.3

Upload page

Should there be on upload page dropdowns to select division, group and document type? Yes. How should the interface of this upload page look like?

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 12 (31)

 SVERIGE 2012

We hope that you can guide us here, we have one suggestion below but we want this only to be used as a suggestion. This is a three part wizard type of dialog.

The system behind this picture do have some features, for instance.. the upload of the document (step 1) to the server must be done before we can press finish (step 3) and store it into db. It would be nicer if this can be done a bit more seamingless. Two users should also be able to add two identical files (identical filenames), without getting conflicts (like using the same upload directory on the server) The note component in the picture above is of course to small. Maybe we can expand it fill it in or have some kind of pop up window where the note is filled in?

5.4

Different handling/processing types

See also section 8.1 Document status for more info on how the statuses are connected.

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 13 (31)

 SVERIGE 2012

As we see it the errand is a document with parameters or values attached to the document. The errand has a division/group/documenttype and all the documentparamters. The document on the other hand is a file (tif, doc, xls etc). The user can pick and errand and start working with it. In this system, working with an errand only means you open it(move it to status o) and then one of the following things can be done archive the errand delete the errand redefine the errand poping the errand

These options should be shown as buttons that the user can click on to decide what type of handling it should be. Below is a short section about each handling type:

44444

Archive document

When the user user is archiving an errend the user must add atleast one(1) type of parameter (f1, f2, f3 or f4) to the document, otherwise it wont be possible to find the document again. Read also about the dynamic archive fields. A document note should also be possible to add.

44444

Delete document

when the user clicks the button delete a question should pop up (or next screen should show) Do you really want to delete the errand? (Y/N). If Y the errand is moved to status d (deleted). If N the user is redirected to the previous screen. Deleting the document means changing of status to d not deleting the actual document in db For this just a confirm popup can be shown with yes/no. On yes document can be deleted and user redirected to list of documents (or list of queues?). On no user will just stay on same page without its reload.

We think If user says click no, the user shall be redirected to the queue page again. The status of the document shall be updated or reseted to status new/n again.

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 14 (31)

 SVERIGE 2012

44444

Redefine document

Redefining an errand simply means moving it back the queue, either to the same documenttype or a new documenttype. In this way its possible to send the errand on to another department or another person. The errand can be in the wrong queue for some reason. When the errand is send back by redefining it, the status should be r.

44444

Pop document

Poping a document, this is when the document is archived or handled but to a different status p. When the user chose pop handling the user has to set a specific pop-date when the document will be sent back to the system again. The user can also specify a specific document type that the document will be sent back to. In this way, the system can have errands which will be sent back to the system. For an example, an agreement that need to be renewed: the user can set a specific date next year and that is the date when the errand will be moved back into the queue again. It should also be possible to enter a note and archive-data to the document. The note is particular important since this might have some processing information that will be displayed to the operator once the document is poped or moved back to the queue again. The pop functionality is described further in chapter: 5.9.

5.5

The Queue and Errandhandling

When the user has logged in to the system the default home page will be the errandhandling page. Example:

rendehantering = Queue

arkiv = archive page ladda upp = upload

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 15 (31)

 SVERIGE 2012

44444

Choosing division and group

The first time the user logs on, the user has to chose which company to work in, but if the user has a default division set (in table user.user_default_division) this division shold automatically be set. All divisions must still be listed in the listbox so its possible to start working within a different division. The groups are listed in the second listbox. This must be updated according to which division the user chosen (divison id is an inparameter) When both these values are set it should be ok to press the ok button (thus generating the groupboxes). If both values are not set this and the user tries to press the ok button, this should generate some kind of errormessage saying something like Please chose division and group.

Cachehandling Our initial though was that we should have a default_group and a default_division field connected to the user so that each user had their own default group and divison. But we have changed our mind about this. Instead we want the the last selected group and division to be cached and preselected if the user has processed any errands. The reason for this is that we think the usually the user is working in the same queue most of the time, it would then be a hassle to have to choose values from these dropdowns only to list the queues. At the same time as we have this functionality with caching, it must always be possible to choose another queue. Read also the chapter 5.5.5 where this is described What should happen when the user has processed and errand.

44444

Listing the queue

We have done some small changes to this view, removed one column and used strikethru on some text below. Below picture is an example of how it can look when listen the queues. The query should list all documenttypes and how many documents there are in each queue. The documentstate should be either n, r, or q.

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 16 (31)

 SVERIGE 2012

The documenttypes are listed. The blue number shows how many errands/document there is in queue for each documenttype. Clicking the first figure would open the errand which is oldest in the queue. Obviously two users should not be allowed to open the same errand so some kind of queue class must be implemented to handle this.

Static handling / Queuehandling If there is only one errand in the queue left but there are several people working in the queue, only one user should be able to start working with the document. If two users clicks at the same time on the queue, trying to start work on the document, one of them would receive a message saying there are no documents in queue.

The date displayed shows the oldest errand/document (timecreated).

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 17 (31)

 SVERIGE 2012

The last column is another view that will show each individual errand in the queue. This is useful if the users want to start working with a specific document. This view is described in the following chapter. Should this page have any type of sorting, paging (if too many rows), filtering or search functionality? No not in this view, but in the archive Yes.

44444

Detailed view of errands (for each doctype)

This is the view which is shown when clicking in the picture above (displaying the errands in each documenttype) Document.DocumentId, Document.createdtime Document.Alarmtime ( calculated field from timecreated+documenttype.maxhours, this field is calculate when the documents are inserted so the alarmtime is already set) How will value of this AlartTime field be used? It is clear from where and how its value will be set, but how will it be used and with what purpose? The alarmtime is passed when (timecreated+documenttype.maxhours > sysdate). So its only when this has happened that we want to highlight that there is a alarm for this queue. We dont need to display the actual alarmtime for each errand, but we still want the feature to highlight the errand that has passed the alarmtime. Maybe you can come up with some nice idea of this? Maybe an Icon with a red !

Best Effort!It would be nice also to have this alarm-feature displayed in the overview of the queues as well. Because the operator might want to see that there is errands with an alarmtime (that is passed) also in the overview for that documenttype (just as an indication)

Documenttype.name a button or a link where documentinfo is displayed (this view is described in the next chapter) a button or a link to begin working/processing the document.

Should this page have any type of sorting, paging (if too many rows), filtering or search functionality? Yes that would be good.

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 18 (31)

 SVERIGE 2012

with the default browser for that document type.

44444

Processing a document

To handle or process a document is very much like starting a wizard that goes thru a number of steps. The different functions have been described earlier in this document. This pictures shows an example of how this might look like (the grid should maybe be replaced by regular fields also):

Available functions should be: information about the document beeing proccessed (above in the grid). This doesnt have to be in a grid.. functions buttons: archive, redefine, pop and delete.

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 19 (31)

 SVERIGE 2012

According to provided info about processing a document, there should be some type of locking functionality for each document. Which means that when somebody has started working on a document (have gone to the screen described above and changed document status to o) it should be locked exclusively to this user and nobody else can start processing it too until it is released. Please, correct me if I understood something wrong. Now queuestions here: Is this what UserId field in Document table was designed for? To store to which user a document is exclusively locked for processing? And, what is more important, how will unlocking happen? It is clear that it will happen auto when user will do one of the actions he can using buttons on interface above. But what if he will not at all or will not for some time? Should document return to his previous status from o opened auto? How will this happen and under what circumstances? Should there be some logic to check if user who processes a document is active and if he is do not unlock it? What if a user just closes his browser? And so on.

Yes its correct. The userfield is for storing the most recent activity on the document , and this means when some user has updated the status on the document. The history of the document (who has changed status, will be saved to the table: doclog). I see now that this filed might be omitted ..but I can be quite good to have this stored on the documentable also for convenience, otherswise we need to go down in doclog and check who is/has been working with the document most recent. The resetting of open arrrends .. that is supposed to be solved by utilityprogram. This is not in scope of the development,( mainly because we feel that we have not had the time to set the requirement for it.)

44444 What should happen when the user has processed or handeled a document?
When the document has been processed (in any way described below).. this should happen:

The user shall be redirected to a confirmation/summary page where information says something like: Your errand has been archived/delete/handled. Two buttons /options shall be available. 1. Pick a new errand from the same queue. The same queue is the same groupbox( combination of documenttype and group). The errand that will be picked shall be the oldest errand in the queue. When this option is choosen the user is redirected to the view described in 5.5.4. 2. Back to overview of queues. The last chosen division and group shall be automatically displayed. (This functionality will replace the function with default_group and

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 20 (31)

 SVERIGE 2012

default_division.) When this option is choosen the user is redirected to the view described in 5.5.2

44444

Archiving

When the user user is archiving an errend the user must add atleast one(1) type of parameter (f1, f2, f3 or f4) to the document, otherwise it wont be possible to find the document again. Read also about the dynamic archive fields. A document note should also be possible to add. Read about the dynamic archive fields in the chapter: #8.1.Use of Dynamic archive fields| outline .

In short: we have suggested that this should be implemented in db but a webconfig solution is also perfectly fine. The name of the parameter can be hardcoded so that doesnt have to be dynamically implemented. The only thing that needs to be dynamically is the validation. But read our explanation in Use of Dynamic archive fields

44444

Pop functionality

When the user chose pophandling the user has to set a specific pop-date when the document will be sent back to the system again. The user can also specify a specific documenttype that the document will be sent back to. In this way, the system can have errands which will be sent back to the queue. For an example an agreement that need to be renewed: the user can set a specific date next year and that is the date when the errand will be moved back into the same queue again or into a specific queue, for example agreement renewal queue.

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 21 (31)

 SVERIGE 2012

popdate is the date when the errand will be moved back to queue. This will be done by a the server utility program that checks for all poperrands and when poptime is > sysdate it will change the status to q. Our remark here is that this can be done by the website itself too without a problem. For example when a user opens list of his queues, we can also check all those that are with status p and that are for his division and group. If there are any change status here. Only it may not always send emails in time, if you are going to use them.

4 duedate is the new alarmtime interval for the errand once it has been moved back to the queue. When the document /errand is moved back to the queue it will get a new timecreated. The new alarmtime is the timecreated + duedate. The duedate is a of date type in the above picture but it might be better to have it has a string or integer, specifing the number of days the errand should be processed in once in the queue. The duedate should have the label Number of days for the errand to be handled in Functionality above about different dates and their usage is not quite clear. Can you explain how will these dates be used? Popdate is clear. It is the date when document will change his status, but what about due date? What is it for? Why are all these date field changes needed? Will document pop again if not processed? Yes you are right. Duedate is not needed..we will remove this req.. 4 documenttype, if set, is the documenttype that the errand will be poped to.

!! In the adminstration interface for the groupboxes (when removing a documenttype to the
group), there should be a check so its not possible to close a groupbox that have errands wating to be poped to that group. 4 email is a an emailadress that will be notified when the errand has been poped into the queue again. This is also done by the utility-server-program. It should be possible to enter several emailadresses, (delimiter ;) removed function regarding email..not needed. Example of the pop dialog:

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 22 (31)

 SVERIGE 2012

44444

Redefining

Redefining is when the errand is sent back to the queue again. It shall also be possible to send the errand back to same documenttype. The divisions and groups must be listed in before the user can chose the documenttype. According to above, interface for this action on document should have document type dropdown defaulting to current documents type and button to proceed or cancel, correct? Or will there be 3 dropdowns there? Division, Group and Document Type populating one by another? You are right. It will be three dropdowns, but we want the last division/group to be default chosen (cached for that user).

When redefining it shall aslo be possible to enter archiving metadata (see section #5.3.1.Archive document |outline)

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 23 (31)

 SVERIGE 2012

5.6

Archive search page dialog Searchable fields archive

44444
document id timecreated

The dateformat must be YYYY-MM-DD. It must be possible to search between two dates. Some datecomponent for this should be used and two fields: fromdate, to date archivefields (with open_gui = 1) division, group, documenttypes Default option for these should be -All- . status

44444
Id Documenttype

fields Displayed in grid , archive

User Status Timecreated Timeclosed Note [noheading] iconimage

44444

Date function

We want to have a function added to the dates in the archive. If a company have a lot of errands it will become very slow if searching in tables where there is load of records (maybe millions) so we want to be able to set a default date within a specific interval. This interval should be configurable (web.config?) . As an example it can be a variable like: Arhive_date_from_days=14

This would automatically set the date in the arhivepage to the last two weeks. (or only the from date value to : sysdate -14) If the parameter would be set like this: Arhive_date_from_days=0 it would not set any default values in archive for the date.

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 24 (31)

 SVERIGE 2012

44444

Detailed view in archive archive

Read the chapter Document Info and Document Note and Document LOG. All the information described in next chapter should be possible to view in a detailed view in archive.

5.7

Document Info and Document Note and Document LOG

Before a user starts to work/process a document or when viewing the errand in archive, the user must be able to view the information about the document/errand. Document info is the information regarding the document.

Document

Note

Doc log

Link to user is missing. A timecreated is also needed.

The state, documenttype, wich user last processed it etc. The history of the document is also information that might be useful and this information is stored in the doclog table. Who has redefined it? Who as archived it? Etc.. The document note is also part of the documentinfo but its a little bit more complex and used in a slightly different way. We have been thinking of where in the system this information will be used. And it will be used in archive page, where the user can search and find information on all errands. It will also be used in the errand handling where the user is adding notes on the document.

Our suggestion is that all the documentinformation is listed in a dialog together with the documentnotes. This dialog can then be used in both the archive page and when viewing the errands in the queue (where the user is picking the errands). The documentnote can be quite large with a lot of text in it. We still want some kind of overview over the notes. It would be nice if this can be solved by having some kind of tab that is extended when clicking on it so its possible to view the whole note. When the note is minimized it should still be possible to see the first couple of lines in it (up to a predefined number of charachters). The notes should be listed in order so the latest notes are highest in the list. It must be possible to see who have created the note, when it was created.

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 25 (31)

 SVERIGE 2012

Show less or more of document note is not a big problem at all. We can implement it. But there are other queuestions about document notes here: According to database diagram document notes are stored in their own table Note. Can any user add any new note for any document he can see? Yes. The notes are only added in the errandhandling. We see that there is things missing regarding the notes in the db design. The note should be connected to the user (obviously). Also a timcreated on the note is needed. Can notes be edited or deleted by any user? ADE of notes is not explained at all. Please, clarify. The note shall not be possible to edit or delete. Adding notes should be possible in the errandhandling page. How will the user add a note to document? If the user wants to add a note to the document, the user has to pick the errand from the detailed view of errands (5.5.3). If the user wants to leave it in the queue but still add a note? This can be done by picking the errand and then redefining it to the same queue again. How is user linked to the note? We are not quite sure about this. We have been thinking that we should store a record in doclog table when the user has added a note but maybe (at this point) we think that the note table has a userid reference instead.

What is Doclog? All the document-meta-data should be stored in a log so its possible to find out who has worked with the errand and when this was done, what status the document got etc. How long time it took when the user handled it (between different statuses)

All the activity on a document should be logged to the doclog table. Example: the document is uploaded to the system. a user starts working on the errand/document.

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 26 (31)

 SVERIGE 2012

the user redefined the document, thus creating a row

5.8

Opening a document

When the user presses the icon-image for the document the document is streamed to the client and opened.

6
6.1

FUNCTION/PROCESS DESCRIPTION
Document status

This picture is an event state diagram. It describes how the different status are connected.

Id n o a d r

Name New Open Archived Deleted Redefined

Description New errand Opened errand, a user has started to work on the errand. Archived errand The document is trahsbin, ie will not show in queue but will still be searhable on the archivepage. Errand has been redefined, routed into a different documenttype.

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 27 (31)

 SVERIGE 2012

Pop

Errand which is archived but will be popped to the system again, meaning it will return to status r

Just to clarify completely: when a document has been archived, it will always stay with this status, is this correct? Like deleted? q on the diagram is this separate status (not explained in table) or will this actually by r status and there is a mistake in the diagram? !! GUI function for status r The document icon should be emphasized for the status r. All the document that has status r has already been processed by another user.. to make this visible in the gui, these documents should have a slightly altered colour to make them stand out a little bit in the grid. Not much but just enough to make these documents visible.

6.2

Use of Dynamic archive fields

The table Archive_fields is configured by high user access level. It shall be possible adminstrate how the archive parameters in table document are displayed and validated.

4 Type can be integer or string.

If integer I should only be possible to store integer values.

4 Min_length and Max_length should be validate so its not possible to store/archive any
parameters outside min and max length.

4 Gui text should be displayed in the search errand dialog and all the other places in GUI.
This is an example of how the table might look like: Field Type F1 F2 F3 F4 Integer integer string Min_length Max_legth Gui_text 4 10 1 8 10 25 customernr phone open _gui 1 1

Its not a requirement that this should be automatically done in gui (if changing this static table.. maybe it can be done by using some css function to update the gui text?

customerorder 1 0

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 28 (31)

 SVERIGE 2012

The table Archive_fields is related to the document table: In my opinion, there is one big problem in database design about these dynamic fields, if you want them to be dynamic of course. If you need them completely dynamic and completely configurable (adding new ones or removing old ones directly from admin pages), there should be one more table that will be linking Document table and Archive_fields table. This new table, say named ArchiveData, will have all the actual values of the fields configured AND foreign keys to both Document table AND Archive_fields table. This will mean that you will be able to change Archive_fields tables data without adding new fields to Document table which does not make any sense. After adding this table, fields F1, F2, in Document table can be omitted. Otherwise we do not see any problem with implementation of this.

It feels like it is many things that play a part of how we decide to deal with this issue. We have the userroles, and the language plugin . We have been discussing the language solution which basically would replace this functionality, but we feel that this is a bit overkill since we only (most likely) will be having Swedish customers. The said, we dont know how much the price is for the language plugin how much would it be in time and money to add this ? The archive-fields also has a connection to the roles, in that these should be configured by the higher user role on the admin pages, but as we have come to understand.. this userrole is actually not needed (see the section on the high userrole), if we/or the user have the possibliltiy to change password . We will probably go through the application and translate all the English to Swedish manually. So the naming of these files are maybe not that big of a deal. But we still need some way to validate the fields. So part of this functionality is still needed but it may not be required to have specific db table for it a web.config file configuration of this is also perfectly fine. Our opinion is that you can solve this in any way as long as we can dynamically, by config, set the validation of how many characters or numbers a certain field can have. Just to clarify .. this is only done once, and that is when the system is set up. Its not something that will dynamically be added during the lifetime of the system. I think you are thinking correct with having a separate archive table.. if we would add dynamic field during the lifetime of the systems. We discussed having a table like this but it will affect performance of adding a separate table with archive data, so at the moment we still think its best to store the archive data in the document table.

7
7.1

UTIL PROGRAM OUT OF SCOPE

Documentresetter functionality

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 29 (31)

 SVERIGE 2012

This section is not ready yet.. we need to think more about this. I guess its some kind of serverprogram needed..? or? This is described later on in Utility section.. but the utility program is not in scope at the moment A server program that shall have functions to send errand back to the system (if a user picks and errand and then go on lunch or leave for the day.. the errand need to be sent back to the system again). It should be configureable. It would be nice if this was possible to configure from a webpage, but cheap and simple solution will also be ok. 4 How many minutes shall pass before the errand is send back to the queue? 4 How often should the program do this check.?

7.2

Delete old errands

Delete old errands than xx days. Status should d (deleted) but this should be possible to configure. Someone might want to delete archived errand also and have a different date on those.

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 30 (31)

 SVERIGE 2012

GLOSSARY
Term 1

ABBREVIATIONS
Term 1

REFERENCES
[1]

Version: 1 Date: 2012-01-20

. Implementation Specification

Page 31 (31)