Fixed inconsistencies in queries that would result in errors because
the parameters were missing. Updating a guest is an example that had
this issue. After checking parameters should all be supplied where
needed.
The calculations used in the reports were calulating based off the
owed column which mathematically did not make sense since we are looking
for the daily.
This commit adds another piece of functinality allowing the staff to
issue penalties. This currently just charges users for their owed amount
and there are no actual penalty fees. The design document did not call
for that. There is also some documentation that was written. The next
several set of commits are likely to be documentation.
This is a small commit to include the feature for paying for a
reservation, specifically only the 60-day-in-advance reservation type as
the others are paid for at specific periods. Other fixes include just
some formatting for reports.
This finishes the first iteration of the project. Reports have been
tested and are functional in terms of writing out and outputting some
form of text. There are still a few bugs here and there that are found
but ultimately this commit is so testing can begin.
Since the changes are too large to individually summarize, here is the
generalization:
Reports have been integrated into the admin mode. They write out to text
files rather than export to say email or a printer as it was not to be
considered for this version. The files are appended too and exist in the
debug director of the project. I made this easier to find by outputting
where the files were output to after running the report.
Other changes included some bug fixes, optimizations, and a few bit of
automatic cleanup. This may lead to sylistic inconsistencies.
Documentation will come in a later commit.
This commit versions the inital classes used for reporting. Some of the
manager classes have been adjusted so that they can also be used in the
reporting system since the queries are very similar. The terminal
commands and flow have been improved to further close in on the design
spec. Guests who make reservations now abide by the fixed rules
determined by the doc. For example Prepaid and 60 day reservations have
requirements on how far away a reservation needs to be at minimum. The
reservation creation process now takes this into account. The base rate
functionality has been hooked up and the queries have been verified to
work at least once. The same applies for CheckIn() and CheckOut()
functions.
This commit branch has been muddled with changes that are out of scope
and cover more than just the models. Specifically it includes
completion of basic guest related models, database access, command line interface
integration and preventing SQL injection.
Total summary of changes:
**IMPORTANT CHANGE: All queries are now parameterized to prevent SQL
injections. Prior versions are subject to it since the strings were
built.
- HotelManager
This class is used to provide database operations that are outside of
scope from a given model. Furthermore if there is no model to work off
of, such as creating a new model based off an existing entry, these
functions live outside of the model since it makes no sense for models
to contain functions where it would retrieve itself with no context.
Realistically this could be placed in an empty constructor and address
itself, however, for now this functionality has been moved off the model
since it is a one use and is not guaranteed to generate a guest. Some
functionality for the coming employee management functions are already
in there since they share overlap with the guest module. Specifically
GetBaseRate for checking and getting the base rate.
- DatabaseManager
This class has mostly migrated functionality out or switch to
parameterized query generation to prevent SQL injections.
- Guest, Reservation, and Transaction Classes
Migrated functionality to create the database entry and a new entry of
guest upon creation as well as update them.
- Program (Terminal app)
Fully integrated the guest module. Has not undergone extensive testing
but does work as of this commit.
The HotelManager class now has been connected to some aspects of the
command line interface and is functioning for a few cases such as
logging in as a specific guest via email, chaging a guests information
and creating a new guest account. This was implemented first over the
reservation system to test and implement something on a smaller scale.
Furthermore, the reservation depends on an existing guest account since
a Guest ID needs to be linked to the reservation that is created.
Other changes include redesigning, tweaking/ adjusting, and/ or fixing
of other modules that have not yet been implemented or are partially
implemented.
This is another commit to mostly version the code. There have been a
considerable number of changes and there is functionality that I am
still determining whether it should lie within the manager or the model
class itself. It makes the most sense to possibly add the "Update" or
database manipulation functions on the models themselves. On the other
hand, instead of creating and generating the ID in the model, the
current design is to create the entry in the database first, get the
last insert row ID and create a new and complete model that is returned
back by the function. This allows us to leverage the autoincrement
functionality of the database rather than trying to design a function
and/ or make an additional call to the database.
**NOTE: Code is non-functional due to some classes not having their
errors resolved.
This commit introduces a large number of changes. Namely there are a
number of additions to a new set of classes that manage the database
and/ or the models shared between the code and databse. There is
fragmented non-functional code in this commit and there may be debug/
old code that still needs to be removed. This commit is just to version
these changes as they were not commited previously. There is also some
console interface code written, but has next to no functionality
attached to any existing prompts. More details will be published per .cs
file, ie specific manager or model, once they are finished as they are
undergoing rapid and significant changes regularly.
This commit includes the following models:
- Guest
- Reservation
- Room
- Transaction
The guest model is used to represent a guest which will create a unique
guest entry represented through its ID. The model also collects
represents and reflects a guests first and last name and their personal
information including email and credit card, phone number still needs to
be included.
The reservation model focuses on #9. See the issue for more specific
details. The changes made to better define this model include changing
the original Cancellation variable to a more meaningful one called
Status. The Status variable can either be Active, Changed, or Cancelled
and enums are used as a better approach than creating and setting an int
value for an int variable. The same approach was used for the
reservation types. Furthermore, the original model was missing the
StartDate and EndDate, confusing them for the CheckIn and CheckOut date,
which can, but is not guaranteed to be identical. NoShow was moved from
the transaction model to the reservation model because it made more
sense.
The Transaction and Room models are currently empty and were created in
preperation of work. Transaction, formerly Payments, did have a model
built, however git stash did not properly store these changes.
Additional changes include the beginning of working on the main
Program.cs, however, this was mostly to ensure that the console was
outputting and the project was building.
Other (less important) notes...
A .gitignore has been added for C#, this is modified to include .vs
files since they are mostly cache files. If this breaks the project it
can always be dropped later.
The project file itself has been versioned, it may not play nice on
other machines, but ideally should be fine and nothing should go wrong
when running the project file.
