Mirabito - Aykut, Ayberk; Aydemir, Necati M.; Demir, Aydin

Week 1

Date: 09/25/2022

Attandence: Ayberk Can Aykut, Aydın Can Demir, Necati Mert Aydemir

---

Accomplishments:

- The first meeting was done with Mr.Abhineet, Mr.Eric and Professor Jones.

- Our team members set up Visual Studio 2022, .NET 6 SDK, Angular and checked some tutorials for .NET Entity Framework and Angular as requested. 

- To get started with Angular, TypeScript syntax was learned and basic component hierarchy was studied.

- Since our team's overall familiarity with the Angular and our anticipation that .NET will have most of the workload for our project, we prioritized learning as much .NET as possible rather than Angular.

Problems:

- No problem occurred this week.

To-Do:

- The second meeting will be hold 09/27/2022.

- The requirements of the project and the general work plan will be clarified after the meeting.

- Studying of Entity Framework and Angular will continue.

Week 2

Date: 10/02/2022

Attandence: Ayberk Can Aykut, Aydın Can Demir, Necati Mert Aydemir

---

Accomplishments:

- The second meeting was done with the team, Mr.Abhineet and Professor Jones.

- As requested, we looked on to more details on .Net Entity Framework, Angular and their integration with each other.

- Our team achieved a better understanding on EF6 Code-First approach and Reactive Form component.

- Created a demo website with Angular that is connected to a web API developed in EF6.

Problems:

- No problems yet...

To-Do:

- Prepare for the demonstration in 10/04/2022.

- Studying of Entity Framework and Angular will continue.

- Rest of it will be decided after the 3rd meeting.

Week 3

Date: 10/09/2022

Attandence: Ayberk Can Aykut, Aydın Can Demir, Necati Mert Aydemir

---

Accomplishments:

- The bootstrap and alertifyjs modules used in the demo were replaced with angular materials upon request. 

- Table and snackbar structures were used from the angular materials module downloaded with NodeJS.

- Checked the Azure environment to have some understanding on Cloud Computing and its relevance to our project.

- Prepared a Design Document regarding the requirements mentioned in our meeting this week.

Problems:

- Azure says we are not eligible for an Azure free account

To-Do:

- Look for Azure alternatives (AWS) for learning more on cloud computing

- Talk about the Design Document in the upcoming meeting to add some new key points if needed.

- Studying continues.

Week 4

Date: 10/16/2022

Attandence: Ayberk Can Aykut, Aydın Can Demir, Necati Mert Aydemir

---

Accomplishments:

- Tables for timesheet and employee were created in the database. We started to develop on the backend side with .Net.

- On the angular side, we developed the front end for the employee time module based on the images that Mr.Abhineet sent.

- We have uploaded client and backend applications we developed using .Net and Angular to the repository created by Abhineet on BitBucket.

- We learned about repository management using SourceTree.

- Thanks to Watson on the hub, Azure account was created by Mert (problem solved).

- The design document has been updated and visuals have been added as requested.

Problems:

- We're having trouble connecting to Azure all together.

- We are trying to connect the backend and frontend applications that we have developed, since we are trying to run the database in the cloud without any problems, we decided to code the requests on the frontend after the base URL we created in the cloud works properly.

To-Do:

- Providing trouble-free access by all team members to the database in the cloud.

- Connecting backend and frontend applications.

- Changing applications with the feedbacks we will receive in the next meeting

Week 5

Date: 10/23/2022

Attandence: Ayberk Can Aykut, Aydın Can Demir, Necati Mert Aydemir

---

Accomplishments:

- Normally, we had a column in the TimeSheet table called "isOngoing" and it's main purpose was to see if that individual TimeSheet is continuing or not. With that, we were able to have constraints such as not allowing our users to create another TimeSheet if they have an ongoing timesheet or not allowing them to call the API call EndSheet if the employee has no ongoing TimeSheet etc. Also, we were holding today's sheets and archived sheets in the same table which would potentially cause some delays in the system with more entries registered. As discussed in the meeting, rather than having a single TimeSheet table for every instance, we divided the current TimeSheet table into 2 different TimeSheet tables, called TimeSheetDaily and TimeSheetArchive. As their names suggest, TimeSheetDaily is for the current day's timesheet entries while TimeSheetArchive is for every other day's entries.

- We also implemented a API call called EndDay that is designed to be called automatically when the day ends. It's functionality is deleting left out entries inside the TimeSheetDaily for the day and adding them to the TimeSheet Archive.

- We also have some Get API calls for View TimeSheets functionality. One of them is returning every single entry of an Employee in the TimeSheetArchive while the other one is giving weekly TimeSheets. Weekly TimeSheet display takes the employee ID and a number called "dist". "dist" means the requested weeks difference between this week. If a user enters 0 for the "dist", it will give this weeks entries for that employee. If the user enters 2, it will give the entries that were stored 2 weeks ago.

- A simple employee Id login interface has been created for the demo on Angular. Entries made without providing an Employee id were checked with an activated guard, and the entries made with a direct url without providing an Employee id were redirected to the login page. Employee id value is saved in session storage so that the entered id is remembered in the system as long as the tab is open. 

- Frontend and backend are connected. Buttons became functional. All buttons except the view time sheet in the Time module, which are clock in, clock out, go to lunch and return from lunch buttons work properly.

Problems:

- No problem this week.

To-Do:

- Functions will be written for the view timesheet button and time sheets in the archive will be requested.
- View Timesheet button will be active.
- View Timesheet by Week functionality will be added.
- .Net identity framework will be checked.
- Will look onto "claims".
- And more depending on the meeting next week.

Week 6

Date: 10/30/2022

Attandence: Ayberk Can Aykut, Aydın Can Demir, Necati Mert Aydemir

---

Accomplishments:

- Due to Azure Free Trial has ended, we couldn't demonstrate the accomplishments we done in week 5 since all of the data we are manipulating were in the cloud and we had no access to those data without a continuing subscription. Rather than renewing our subscription with paying or using student subscriptions of Ayberk and Aydın, we decided to continue our demonstrations with our local database. Normally, using a cloud for database storage would be easier since the same data could be accessed from different machines (which is time-efficient for testing). However, at some point, we'd have to use the database services of Mirabito so worrying about cloud access is unnecessary for now.

- During this week's demonstration, we couldn't revert the .NET's access to localhost from Azure. It was automatically trying to access the Azure database even though we changed the "ConnectionString" in a way to access the local database. After the presentation, we realized that it was due to a configuration we made while publishing the database to the cloud. It turned out that when we tried to use the command "dotnet ef database update", .NET EF was checking the database access information in a file called Secrets.json and ignoring the configurations in the "ConnectionString". Deleting the Secrets.json for good fixed the whole issue.

- With the .NET EF Code-First approach, we were able to get the exact same table structure as in the cloud (since the Models and the Migration files were unchanged). One caveat is that we have to manually add the rows inside our tables for every different machine since the structure takes the local databases into consideration.

- The components made for all states were combined into one module by generating the TimeClock Module. ngIf for state transitions, clock functions and enumeration for states, and service structures were implemented.

- Service for time sheets has been reviewed. Error handling and pipe mechanisms have been added. Snackbar notifications for errors have been added.

Problems:

- none

To-Do:

- View Timesheet by Week functionality will be added.

- .NET identity framework will be checked.

- Will look onto "claims".

- And more depending on the meeting next week.

Week 7

Date: 11/06/2022

Attandence: Ayberk Can Aykut, Aydın Can Demir, Necati Mert Aydemir

---

Accomplishments:

- In the meeting this week, we discussed a calendar outline called "Master Calendar" that is structured in a way to divide a year into "Week Pairs". Week Pairs are useful for the management or the HR to visualize the work times and payments of the employees. Rather than having a format of Month/Day, Master Calendar will work with the format of WeekPair(0-20)/Day(0-13) for search efficiency. Each day will have its own attributes that will provide useful information to the HR like is the day a national holiday or if is there a special event assigned to that specific day etc. For the current plan, the initial implementation of the Master Calendar is going to work for the current year only. This means, when we get to a new year (2022 to 2023), the fixed Master Calendar entry for this year is going to be deleted and updated with the new year's WeekPair/Day entries. Archiving and updating entries without deleting can be implemented if requested in the upcoming weeks.

- Before starting to implement the Master Calendar, we decided to have it planned and discuss it further with Mr. Abhineet. For the current plan, we decided to have 3 tables called WeekPair, Day, and CalendarDay. WeekPair will contain a primary key called id that takes the values from 1 to 26, and the start-end dates of the week pair in Gregorian Calendar format (mm/dd/yyyy). The Day table will consist of a primary key similar to the WeekPair's id but takes values from 1 to 14, the day of the week (Monday, Friday), and the exact date in Gregorian Calendar format. Finally, for the CalendarDay table, a composite key in the format of (WeekPairId, DayId) will be used. These keys are also going to be foreign keys that are connected to Day and WeekPair tables respectively. We can think of CalendarDay as the main table for this database while Day and WeekPair tables are generally for optimization and normalization purposes. Additional columns to the CalendarDay like "IsHoliday" or "FurtherDetails" can be considered according to the inputs we will get from Mr. Abhineet in next week's meeting, regarding the current outline of the Master Calendar.

- Information texts have been added to the time clock module. The details of the previous entry and the working time were added as an informative text under the clock.

- Deprecated functions have been changed to their current recommended versions. Error handling mechanisms have been rewritten. As requested, redirecting to a different page in case of error has been removed. Errors that occurred in the system were displayed to the user with the error status code. Snackbar notifications added to time clock module.

- As discussed in the previous meeting, functional confirmation dialog service and pop-up screen component were created for go to lunch, return from lunch and clock out buttons and connected to the system.

- Improvements were made with css for visualization. Development of time-clock module was completed. The file layout of services and models has been changed as desired. Services, pipes and models are placed in the created core folder.

- The component to be directed with the View Timesheet button has been created. Timesheet model in the Angular was updated according to changes in .NET. Function was written in time service to retrieve timesheet entries as a list of timesheets from the API, and its operation was tested. It works as desired at the moment. Development in progress...

Problems:

- none

To-Do:

- View Timesheet by Week functionality will be added. (Working on creating the table and displaying the received data)

- .NET identity framework will be checked.

- And more depending on the meeting next week.

Week 8

Date: 11/13/2022

Attandence: Ayberk Can Aykut, Aydın Can Demir, Necati Mert Aydemir

---

Accomplishments:

- Master Calendar API call and tables are ready. The table structure is almost the same as we presented. The difference is that, for the CalendarDays table, we decided to have the exact date (Gregorian format) as the primary key rather than the <WeekPairId, DayId> pair. The reason is that it will be easier to access the <WeekPairId, DayId> pair from the database with a query given the requested date, compared to calculating it in the back end.

- Changed the structure of Managers. Rather than having a manager table, we decided to assign managers in the column of our Employee table. So, the ManagerId column in the Employee table takes an EmployeeId, that is, the Manager's EmployeeId. Assigning a Manager to an employee can be done with the new AssignManager API call, which takes an employeeId and a managerId. The function does the necessary checks to complete the assignment process.

- Divided the controllers and models into separate folders (employee, timesheets, mastercalendar) in the back-end

- Created an API call that gets the latest archive timesheet with the given employee id as Ayberk requested for front-end

- View time sheet page is completed. Expandable table format has been added to the page as requested. Comments are now visible when pressing on entries. CSS improvements were made in the view time sheet.

- Recall feature has been added for the time clock module. In the initialization phase, the state Enum in Angular is determined by taking the status code from the database with the API call. Error handling mechanisms have been written. Timesheet service has been updated.

- The creation of the date objects required for the information texts and the time calculations were done in the front-end part in the previous version (before the recall feature was added). Now, date and time span objects from the back-end are interpreted and converted to date objects in Angular. Time calculation functions have been recoded.

- Getting comment and source data in entries is now provided. The necessary function to find the source has been coded. Necessary changes have been made to add a comment. Timesheet service and the module using the service have been updated All the features requested in the entries are now supported

Problems:

- none

To-Do:

- Integration of the changes done in back end and front end.

- Testing.

- More, depending on the meeting next week.

Week 9

Date: 11/20/2022

Attandence: Ayberk Can Aykut, Aydın Can Demir, Necati Mert Aydemir

---

Accomplishments:

- Acyclic Manager-Employee relationships. We had a problem that lets it possible to have a manager cycle. User "A" could be the manager of "B" and user "B" could be the manager of "A". Since it is illogical, we put a check that terminates the assignment action if it is going to result in a manager-employee cycle.

- GetPageNum. When a user closes the TimeClock page and opens it up again, they are directed to the page where they left off. The logic of this use case was handled in the front end. In case the front end would like to simplify the code structure, a GetPageNum API call is created in the back end that returns the ID of the page the user was left off. Page ID is calculated from the TimeSheetDaily and the TimeSheetArchive records of the given employee.

- Archive TimeDuration field. Similar case for GetPageNum functionality, TimeSheet duration is calculated in the front end. But to simplify things, the back-end is providing a TimeDuration attribute in every API call that returns a TimeSheetArchive model. The calculation is done by subtracting the EndTime and StartTime of the given TimeSheet and returning the Time value.

- Utils. For the sake of modularity, a folder called Utils contains functions that are not API calls but use database queries and are used multiple times. These functions can be accessed from other parts of the project.

- Get TimeSheets in a given WeekPair. We had an API call that gave the weekly TimeSheetArchive entries of a given employee. This API call was changed and optimized in a way to supports our Bi-weekly MasterCalendar. Front-end should provide the employee ID and the week pair distance from the current week pair to the target week pair going back.

- Fixed incompatibility between navigation component and log in mechanism.

- Bugs in the system have been detected and resolved, such as the problem of changing and disappearing numbers in the information text display, and the last clock in time being not updated when the page is refreshed.

- The mat-card structure in the time clock module was replaced with an expansion panel in order to adapt to the given visuals. The module now has expansion feature and looks more elegant.

- Upon request, the entries were sorted and the three-story pop-up table structure was added to the time sheet view. Now, when you click on the days, the entries in the day are opened. When you click on the entries, the comments are visible.

Problems:

- Re-rendering of the table with the change of the variable cannot be provided in the ngIf structure written into the table. Solution to this is being investigated.

To-Do:

- Integration of the changes done in back end and front end.

- Displaying entries ,in Timesheet view page, with different display features as only lunch, only working hours and total hours.

- Creating the Status panel and displaying the Employee's Working time statistics on the screen.

- Creating the Master Calendar, integrating it into the system and arranging the API calls

- Testing.

- More, depending on the meeting next week.

Week 10

Date: 11/27/2022

Attandence: Ayberk Can Aykut, Aydın Can Demir, Necati Mert Aydemir

---

Accomplishments:

- A class for error messages: Our API calls return "Ok" if successful, if not; they return "BadRequest". Thanks to these different return results, we get to understand if something going right or wrong on the front end. To be clear, the back end returns error messages with the BadRequest response. These messages are often customized based on specific occasions like when a given employee id does not correspond to a valid employee or when an employee somehow trying to end a timesheet that is not started yet. We compiled these error messages inside a single static class to be accessed. With the given error code and parameters, error messages can be given.

- A controller for TEST API calls: We had API calls specifically for test purposes like "EndDay", "FillCalendarDays", "ArchiveAdd". We carried those API calls to a new controller called TestController. The reason for that is these calls were making other controllers crowded and hard to manage in the SwaggerUI but they are also valuable enough to be kept. So, these calls are still around inside their section.

- Further function assignments in util classes for code reusability: For modularity purposes, some of the functionalities that are doing the same thing are modified in a way to use a single common function.

- Displaying entries ,in Timesheet view page, with different display features as only lunch, only working hours and total hours tasks completed.

- Log In Page and Navigation bar has been changed, new buttons added to nav bar to go back and quit the system.

- Re-rendering of the table with the change of the variable cannot be provided in the ngIf structure written into the table. Solution to this is being investigated problem is solved.

Problems:

- none

To-Do:

- Integration of the changes done in back end and front end.

- Displaying entries ,in Timesheet view page, with different display features as only lunch, only working hours and total hours.

- Creating the Status panel and displaying the Employee's Working time statistics on the screen.

- Creating the Master Calendar, integrating it into the system and arranging the API calls

- Testing.

- More, depending on the meeting next week.

Week 11

Date: 11/27/2022

Attandence: Ayberk Can Aykut, Aydın Can Demir, Necati Mert Aydemir

---

Accomplishments:

- Last log in information text is changed upon request. If the last log in date is more than one day, the text has been changed to include day, hour, minute and date information.

- Manager-subordinate relations are created in employee service. When switching to the time sheet entries page from the Clock module, if the person who logs in is the manager (if she/he has one or more subordinates), she/he will be able to switch between the timesheets of his subordinates from the dropdown in the upper left. Functions and API calls are coded for transitions and integration.

- As requested, the date section in the entries has been removed. Table structure is organized with CSS. The edit button has been added to the created space in the manager view.

- Added dropdown for manager view. If the manager switches to the employee's timesheet, she/he will see an edit button next to the entries. The button opens the entry change panel on the right side. When the edit panel opens, the row color of the entry changes from white to red. If the panel is open, pressing the edit button of the same entry will close the panel.

- A reactive form has been created for time sheet editing. The timesheet model was used to capture the form. When the Edit button is pressed, the timesheet model is copied and only the desired features can be easily changed.

- The API call for timesheet put required for the time sheet edit operation was coded in the timesheet service. It was used in the Timesheet entries component, necessary error handling mechanisms and information texts were created. Snackbar notification was used to show successful and unsuccessful operations.

- After successful editing operations, with the help of ChangeDetectorRef, the table was rendered according to the changes, without refreshing the entire page. In this way, operations can be performed faster and waiting times are reduced.

Problems:

- none

To-Do:

- Integration of the changes done in back end and front end.

- Displaying entries ,in Timesheet view page, with different display features as only lunch, only working hours and total hours.

- Creating the Status panel and displaying the Employee's Working time statistics on the screen.

- Creating the Master Calendar, integrating it into the system and arranging the API calls

- Testing.

- More, depending on the meeting next week.