view release on metacpan or  search on metacpan

lib/App/Dochazka/CLI/Testers.pm  view on Meta::CPAN

=head2 Assign george a password

Fortunately, Dochazka admins can assign any password to any user. This
capability may or may not be useful, depending on whether LDAP
authentication is active at the site. In our current testing scenario, LDAP
authentication is disabled, so the password is taken from the Dochazka
database. So, let's give george a password:

    $ dochazka-cli -u root -p immutable
    ...
    Dochazka(2016-01-27) root ADMIN> emp=george password
    It is important that the new password really be what you intended.
    Therefore, we are going to ask you to enter the desired password
    twice, so you have a chance to double-check. 

    New password      : <type george>
    New password again: <type george again>
    Password changed

Now you can log in with credentials C<george/george>:

    $ dochazka-cli -u george -p george
    ...
    Authenticating to server at http://localhost:5000 as user george
    Server is alive
    Dochazka(2016-01-27) george PASSERBY>




=head1 SESSION 3: EMPLOYEE PRIVILEGE HISTORY

Before you do anything, L<make sure the server is running|"Start the server">.


=head2 Verify state

If you are continuing from Session 2, you can skip this step.

If you are starting over (or from scratch), run the following script to
bring your database into the proper state:

    #!/bin/sh
    cat <<EOF | dochazka-cli -u root -p immutable
    PUT employee nick george { "fullname" : "King George III", "salt" : "a054d158a23c3a07ad0163107ad72a8649597d71", "passhash" : "5cf2c3a23de9db43d2d846172966150e9197717ecd0304bafef3f23fc159df942021dd3aec7b4dbcde87d8a44c1bd905bbba3862989065d012bb46a1...
    EOF


=head2 Log in as the test employee

This just demonstrates that the test employee can log in.

    $ dochazka-cli -u george -p george
    ...
    Authenticating to server at http://localhost:5000 as user george
    Server is alive
    Dochazka(2016-01-27) george PASSERBY>


=head2 Concepts (Dochazka prompt, employee priv levels)

Let's review the information presented in the prompt:

=over

=item Prompt date in parentheses (defaults to current date)

=item Logged-in employee (george)

=item Privilege level of logged-in employee (passerby)

=back

The privilege level deserves closer attention. Dochazka has four privilege
levels:

=over

=item passerby

=item inactive

=item active

=item admin

=back


=head2 George the passerby

The current privilege level is determined by consulting the employee's
privilege history, which is a database table containing records for each
change in the employee's status. Employee status changes, for example, when
the employee is hired, leaves the company, goes on parental leave, etc.

Now, our test employee "george" has a password and can log in. However, he
has no privilege history so his priv level defaults to "passerby" - the
lowest possible level.

In this section, we see that passers-by cannot do much at all in Dochazka:

    $ dochazka-cli -u george -p george
    Dochazka(2016-01-29) george PASSERBY> emp=root profile
    *** REST ERROR ***

    Error encountered on attempted operation "Employee lookup"
    REST operation: GET employee/nick/root/minimal
    HTTP status: 403 Forbidden
    Explanation: DISPATCH_KEEP_TO_YOURSELF: Detected attempt by
    insufficiently privileged user to meddle in another user's affairs
    Permanent? YES

    Dochazka(2016-01-29) george PASSERBY> interval
    *** REST ERROR ***

    Error encountered on attempted operation "Get intervals for employee
    george (EID 3) in range [ 2016-01-29 00:00, 2016-01-29 24:00 )"
    REST operation: GET interval/eid/3/[ 2016-01-29 00:00, 2016-01-29 24:00
    )
    HTTP status: 403 Forbidden
    Explanation: DISPATCH_ACL_CHECK_FAILED: ACL check failed for resource

lib/App/Dochazka/CLI/Testers.pm  view on Meta::CPAN

The first interval object is now in the database. Let's examine it:

    Dochazka(2016-02-03) george ACTIVE> GET interval iid 1
    HTTP status: 200 OK
    Response:
    {  
       "level" : "OK",
       "code" : "DISPATCH_INTERVAL_FOUND",
       "payload" : {
          "long_desc" : "Push pencils",
          "partial" : null,
          "intvl" : "[\"2016-02-03 08:00:00+01\",\"2016-02-03 12:00:00+01\")",
          "iid" : 1,
          "aid" : 1,
          "remark" : null,
          "eid" : 3,
          "code" : null
       },
       "text" : "Found an interval"
    }

The attributes under the "payload" are from the interval object. The "code"
attribute is null in this case because it is not stored in the database. It is
populated on an as-needed basis.


=head2 Modify an interval

We can modify intervals in the same way that we modified the "bike shed"
activity:

    Dochazka(2016-02-03) george ACTIVE> PUT interval iid 1 { "remark" : "BIKESHED" }
    ...

We can even set the "code" attribute to a bogus value in this way:

    Dochazka(2016-02-03) george ACTIVE> PUT interval iid 1 { "code" : "BIKESHED" }
    ...

It does not get stored in the database, however:

    Dochazka(2016-02-03) george ACTIVE> GET interval iid 1 { "code" : "BIKESHED" }
    HTTP status: 200 OK
    Response:
    ...
          "code" : null,
    ...


=head2 Add another interval

Very good, and enough fiddling. In the meantime, George went to lunch, and then
spent the afternoon looking out the window:

    Dochazka(2016-02-03) george ACTIVE> interval 12:30-16:30 work Look out window
    ...
    Interval IID 2
    ["2016-02-03 12:30:00+01","2016-02-03 16:30:00+01") WORK Look out window

Now let's admire George's work. The command INTERVAL should list all
existing intervals for the prompt date:

    Dochazka(2016-02-03) george ACTIVE> interval
    Attendance intervals of george (EID 3)
    in the range [ 2016-02-03 00:00, 2016-02-03 24:00 )

    IID Begin            End              Code Description
    1   2016-02-03 08:00 2016-02-03 12:00 WORK Push pencils
    2   2016-02-03 12:30 2016-02-03 16:30 WORK Look out window


=head2 Concepts (Prompt date)

Let's review once again the information provided by the Dochazka prompt:

=over

=item Prompt date (defaults to current date)

=item Logged-in employee (george in this case)

=item Privilege level of logged-in employee (passerby)

=back

The prompt date defaults to today's date.


=head2 Set the prompt date

The prompt date can be set by the user to any valid date:

    Dochazka(2016-02-03) george ACTIVE> prompt 2016-01-18
    Prompt date changed to 2016-01-18
    Dochazka(2016-01-18) george ACTIVE> prompt 203-12-31
    *** Anomaly detected ***
    Explanation: Encountered invalid date or time ->203-12-31<- (ERR)
    Dochazka(2016-02-03) george ACTIVE> prompt 2016-01-33
    Prompt date changed to 2016-01-33

Oops! (This is a bug.)

=cut

1;