Hardware and Storage Media Register.

The register must retain information about the storage medium, device, service request, collection, and subsequent handover. I developed a data model that connects these stages with the record and its history. Instead of adding information in several independent places, an operator can work with a linked entry. Preserving older data through later changes to forms and views was also important.

I organized the columns of the operational list, combining make, model, and serial number into a readable description. Record details retain the full range of information, including encryption, envelope, service request, and dates of subsequent actions. I corrected duplicated fields and aligned the form, list, and export. A simpler view therefore does not mean losing information needed later for documentation.

I developed the record form and its connection to storage-medium and computer data. Date, time, signature, contact, purpose of handover, and archive location retain their meaning in both the details and the printout. I checked field completeness and how entered content is rendered. The document should describe the same operation saved in the system, without reconstructing it manually from several sources.

I moved important write rules into server functions. Assigning the next number uses a transaction and a location-specific counter; the system also checks for conflicts with an existing record. I organized the handling of simultaneous writes and deliberate editing. This is an important part of an application used by more than one person: a correct form is insufficient if two submissions can overwrite the same entry.

I built synchronization between the storage-media register and the register of retained computers. Matching uses device identifiers and the correct location. The linked computer receives information about the removed drive, its register position, and the appropriate status. A change in one process can therefore update the other, and the operator does not have to repeat the same action in two views.

I developed account, role, and location-access handling in Firebase. Functions verify the identity and permission scope of the person performing an operation. Significant changes leave an audit record. The work also covered Firestore rules and aligning accounts with profiles. Permission to use a button in the interface must match what the data-write layer actually permits.

I prepared a separate environment for checking changes and data-model consistency controls. A quality panel detects missing fields, repeated numbering, and discrepancies between accounts and profiles. I also developed tests for printouts and server functions. This allows later changes to be checked against existing records instead of assessing the application solely with a fresh, empty form.