Expedient and Document Manager

File and Document Manager

Objectives

The student will develop a complete Web system that includes a client-side application and a server-side application using recent technologies and frameworks for development.

Problem Definition

A solution is needed for the problem of poor organization of Files and their documents in a company.

A File is known as a collection of documents that is about a specific topic and has a certain number/key to identify it, which can be alphanumeric.

A document can belong to several Files, therein lies the problem of disorganization, in addition to the administration of the file permissions to the interested users.

Functional Requirements

User Management

The system will only be for use by internal users of the company, so the functionalities of registering new users, as well as modifying user data and deleting or deregistering users are needed.

Another necessary feature is the ability to reset a user's password, in case the user has forgotten his password, resetting it to the default one.

The data that is needed to know about the user is the following:

Username: The username with which the user will log in to the system.

Password: Password with which the user will log in.

Name: The name or names of the user.

Last name (optional): The last name or surname of the user.

Gender (optional): M = Male, F = Female…

Date of birth (optional)

Email: User's email, this will be used to send him system notifications.

Type of user: there are only two types “administrator” and “normal user”

Department (catalog, optional): A value that indicates where the user is from; it is not mandatory because he may not yet have a defined department because he has not been given an official appointment.

Registration date-time: Date-time when the user was registered/registered in the system.

Last modification date: Date-time when the user's record was last modified. If the user's record has not been modified since it was created, this value will be null.

Deleted date-time: If this value is set, the user will be considered deleted (logical deletion).

File Management

For each File, the following data must be saved:

File Type: To indicate what type of File it is; this must be from a catalog.

File Number: This is an alphanumeric data, which helps the user to quickly identify a File; for example, it can be “PROY-2024-0001”, “EMPL-00404”, “ADMIN-2024-00002”... Note: this file number does not necessarily have to be unique, it can be repeated, but it will help in searches.

Tags: Labels that are a brief description of the File; and each file can have several tags; for example: “administration”, “budget”, “pending attention”, “staff”, “under review”...

Opening date: Date on which the File is registered in the system.

Last modification date: Indicates when any of the File's data was last modified; if the File has not been modified, this value must be equal to the opening date.

Completion date (optional): If a file has already been completed, this value must indicate when.

Deleted date and time (optional): Value that indicates when the File was deleted/erased (logical deletion), this means that if this value is set, the file has already been deleted.

Administrator users will be the ones who can create Files, in addition to assigning owners to them (a File can have several owner users).

Only the owners of the files can add documents to it, and an owner can be any type of user (admin or normal user). A user who owns a File can add other users as readers (which means they can only see the content of the File but cannot add new documents), but only administrator users who are owners of the File can add other users as owners.

If an owner user adds a user to the File that had already been previously added, the following scenarios may occur: If the user was previously an owner and the user is added as an owner, there is no problem, and if the user was already a reader and is added as a reader, nothing happens; but if the user is added with a different access than the one to which he was added, he must be informed that the user was previously registered with such permission and confirm that the type of access will be changed from owner to reader or from reader to owner.

Users can upload new documents to the File, but another way to do this is toand adding documents is that a document from another File can be added. Also, when uploading a new document, it must be verified that it has not been uploaded before (it does not matter if the name of the document is different, the system must be able to identify that the document to be uploaded is the same), this to avoid duplicate documents, in case a duplicate document is uploaded, the user must be informed that the document is already registered in addition to indicating which File or Files it is located in.

In the system (specifically in the front-end Web application), once the user is logged in, the Files of which he is the owner or reader must be listed, in addition to indicating the access he has (owner | reader). And only the Files that have not been completed or deleted must be shown. In addition, only owner users can complete a File and only Admin type users who are owners can delete the File. There should also be a section to be able to consult the Files that have already been completed (as long as the user still has access [owner or reader]).

It is worth mentioning that for each file, a history/log is needed to know what actions have been carried out on the file (modification of general data, uploaded document, deleted document...), as well as which user carried out the operation and when (date-time of the operation). This log can only be consulted by owner users who are admin users.

Document Management

As previously mentioned, if a user has owner access, they can upload documents to the File, either by uploading the document directly or searching for a document that has already been uploaded to another File to add it (emphasizing that the same document can belong to several Files).

The types of files allowed for documents that are uploaded to the system are: PDF, word processor files (such as Microsoft Word), spreadsheet files (such as Microsoft Excel), presentations (such as Microsoft Power Point), images (JPEG, PNG, TIFF, GIF).

Also as part of a File document, you may not upload a file, but rather you may save a URL/link where you can access the file.

The important data that you want to know about each document are:

Unique key: this must be a unique alphanumeric identifier that the system generates for the document. This can be a GUID/UUID, or a ULID or generate your own that is not repeated and is not easily predictable.

Document title: The name given to the document you want to save.

Document description (optional). This is a small text that describes what the document has.

Document date (optional). This is the date that the document has, for example, a letter that is written has a certain date, or an official document can have a date, but not all documents can have a date.

File type: This is to be able to identify if the document is a PDF, Word, Excel, etc. file. This value can be a literal of the file type or it can be cataloged.

Size (optional): The size of the file that corresponds to the document. Note that if the file is a URL and/or link, this information is not necessary.

Original file name (optional): The name of the file with which the file was uploaded.

URL or Link (optional): If it is not a file that is uploaded, but rather a reference to a file/document/page accessible via the Internet, the URL from where it can be accessed is saved.

SHA256 (optional): The SHA256 hash of the uploaded file that corresponds to the document.

Date time recorded: The date-time when the file was uploaded.

Date time deleted (optional): Date-time when the document is marked as deleted/erased (soft delete).

For the functionality of deleting/erasing a document, the following rules will apply: Only the users who own the file can delete a document. Also, if the document has already been referenced in another File, this document will not be deleted from the other File, but from the File from which it is being deleted. However, if the document is only in the File from which it is being deleted, then it will be deleted. Note: it is not deleted, only a soft delete is performed.

Non-Functional Requirements

Technologies to be Used on the Client Side

To develop the client-side application, it is required that the application be a React, Angular, Vue or any other framework for front-end development.

Technologies to be Used on the Server Side

On the server side, a Web API REST application must be developed, because later it is planned to develop desktop type applications for Windows and mobile applications on the client side. It is recommended to use frameworks such as Express (using Node JS), Laravel (with PHP), Flask, Fast API (in the case of Python).

For the database, use a relational database, which can be MySQL, PostgreSQL, MariaDB, SQL Server or the RDBMS of your choice.

Security

Authentication implementation to access the system.

Taking into account that in a REST API each request has to be authenticated, it is recommended to use a Token type authentication mechanism: JWT or custom token. “Basic” type authentication is not recommended.

In the database, the password must be stored encrypted, in addition to using a SALT parameter.

Node.js HTML CSS Express JS Laravel

Project ID: #38432334

About the project