As of #62 we infer the type of event using the information stored in database. Why don't we extend this feature to User/UserFactory classes?

A (counter) argument can be that a user can have multiple type, whereas an Event cannot.

We have overfocused how the peerpanda designed their application rather than how we want and are going to implement ours.

By Sunday (5th DEC), I and @MustafaYasirAltunhan are going to

• review the current design
• and revise according to our needs.

We will create the most, if not all, .php files

• those index.php's
• and the util files
• and add method declarations.

Whilst

The implementation of the methods and the preparation of the UI will be left to rest.

refactor the config.php to a method getDatabaseConnection() which returns a PDO object that the caller can assign to any variable of his choice rather than assigning it to $conn variable.

Implementation

A list of the incomplete features

• Disable enroll for the users not allowed in the campus. #85
• change password (profile page)
• Registration page warnings. : @MuhammedCanKucukaslan is working on it.
• Diagnosis submission: #70
• Replace favicon with medical emoji via https://favicon.io/emoji-favicons/medical-symbol
• HesCode validation: #75
• Test Appointment @HikmetSimsir #89
• view coinstructors #93
• User lastname #94
• constants.php file #95
• Forget password: @GirayAkyol #88
• usertype check's in pages, some pages seems to lack this? #94
• lecture creation: #73 and #74

bug fixes

• composer update in forthyhealth.duckdns.org
• navbar fixes
• delete debug echo/print_r statements

Presentation

Final Presentation Slides

• Brief overview of innovative features
• Design pattern(s) that you used
• This part should be a Max of 6. minutes

Demo

• Live demo of the software - 15 minutes
• İş bölümü

Report

• Demo Video: Think of this as a trailer of your software. Showcase your creativity. Maximum of 90 seconds

Final Report (Dec 26 Midnight)

• User Manual @MustafaYasirAltunhan
• Make sure you include step-by-step build instructions for your software. A third person that has the source code should be able to build your software @MuhammedCanKucukaslan
• Make sure include a 1-page description of the work allocation of your team. Use a bullet format to briefly describe the work done throughout the semester.

ps. You're free and allowed to extend this list, however this does not mean you're supposed to delete some code for the sake of extending the list.

As @MustafaYasirAltunhan noticed there seems to be a bug in events page.

We need to update Analysis Report according to feedback and the issues we discussed in person:

• User Types (#1 and #2 .1)
• different possible diagrams for sequence and state models. (#2 .3)
• Inconsistencies among diagrams (and texts) such as "overview in the first report does not match with the mock-up" (#2 .1)
• Writing Scenarios.

The corresponding docs' link is here
https://docs.google.com/document/d/1_tqI3keD3H2CIXaxPY7lkV4SsruKaiPrtV2Ks-vDWCY/edit?usp=sharing, for your convenience.

foreword: I'm writing it just to record the decision.

We have decided to represent users in 3 main user (role) types

EventParticipants
EventControllers
UniversityAdministrators.

Examples of real life representatives are:

Event Participant: e.g. students in lectures, participants at sport center
Event Controller: e.g. instructors in lectures, and sport hall staff
University Administrator: e.g. rector, deans, chairs

Every actor/user is an Event Participant. There are three roles each having different access rights.
Where the thorough list is given in Analysis report .

It is also important to also note that:

EventController can do everything that EventParticipants can do
UniversityAdministrator can do everything that EventController can do

ps. Notify @MustafaYasirAltunhan @MustafaUtkuAydogdu @GirayAkyol @HikmetSimsir

PHP does not allow method overloading (and thus constructor overloading) so we need to find ways to overcome this obstacle.

We can use Factory Pattern

We can call ob_start() in the every script file (eg. index.php).
It delays writing the output untill the end of the script.

It can be dealt using the following procedure

if(isset($_SESSION['id']) ) {
    header("location: ".getRootDirectory());
}
if($_SERVER['REQUEST_METHOD'] == "POST") {
    $_SESSION['op'] = $_POST['op'];
    $_SESSION['ts_id'] = $_POST['ts_id'];
    // clear the request
    unset($_POST);
    header("Refresh:0");
}
else if ($_SERVER['REQUEST_METHOD'] == "GET") { 
    if (isset($_SESSION['op'])) {
        $op = $_SESSION['op'];
        unset($_SESSION['op']);
        
        if ($op == "details") {
            header("location: ../details", true, 301);
        }
        else if ($op == "accept") {
            updateTourSectionStatus($db,"approved");
            header("location: ", true, 301);
        }
        else if ($op == "reject") {
            updateTourSectionStatus($db, "rejected");

            header("location: ", true, 301);
        }
    }
}

I'm unsure but it seems we can handle all headers using the header() method. So all the things we printed (or echoed) will be directly written into body of request (inside the <body> tags). So we won't need to have concern about closing </html> </head> tags etc.

Create a method in config.php that starts a session along with the specified conditions.

We will probably use an AWS server.
AWS gives students to $100 worth credits. However, since March 2021 it automatically shutdowns the device at the end of "session" which is 3 hours , AFAIK. Instead we should buy a free trial account in the name of "one of us" for 1 dollar, and have a stable server.

I can handle the deployment &c.

We can delay this until start of the implementation.

We should have a Logger object that would log to the javascript console to ease the debug process.

In production version we can easily comment out console log function inside the Logger class to avoid any side effect (leak).

For the final version of the req. Analys. Report , we have to deal with some serious problems. Below is a list of most critical ones, however note that there are also other problems that we are not even aware of.

1. The overview in the first report does not match with the mock-up screen. We have to create extra mock-up pages ( such as seperate ones for enrolling to a course and makings sports reservation). Also mock-up pages look a little sloppy, we also have to work on design.

2. What kind of user types there will be in our system is another problem. Although the EventController corresponds to instructors and fitness staff , and this seems good implemention-wise, it creates problem such as a fitness staff type user can access instructor’s features(creating a course page) and vice-versa. To solve the problem we have to go over the overview together and decide the final version and update the diagrams accordingly.

3. This will be a little vague problem, however it exists. We have to come up with more ideas for different possible diagrams for sequence and state models.

@MustafaYasirAltunhan @MuhammedCanKucukaslan @HikmetSimsir @GirayAkyol