view release on metacpan or  search on metacpan

lib/App/Dochazka/Common.pm  view on Meta::CPAN

94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
=item * Privhistory (history of changes in an employee's privilege level)
 
=item * Schedule (a schedule)
 
=item * Schedhistory (history of changes in an employee's schedule)
 
=item * Activities (what kinds of work are recognized)
 
=item * Intervals (the "work", or "attendance", itself)
 
=item * Locks (determining whether a reporting period is locked or not)
 
=item * Components (Mason components, i.e. report templates)
 
=back
 
These classes are described in the following sections.
 
 
=head2 Policy

lib/App/Dochazka/Common.pm  view on Meta::CPAN

172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
Dochazka has four privilege levels: C<admin>, C<active>, C<inactive>, and
C<passerby>: 
 
=over
 
=item * C<admin> -- employee can view, modify, and place/remove locks on her
own attendance data as well as that of other employees; she can also
administer employee accounts and set privilege levels of other employees
 
=item * C<active> -- employee can view her own profile, attendance data,
modify her own unlocked attendance data, and place locks on her attendance
data
 
=item * C<inactive> -- employee can view her own profile and attendance data
 
=item * C<passerby> -- employee can view her own profile
 
=back
 
Dochazka's C<privhistory> object is used to track changes in an employee's
privilege level over time. Each time an employee's privilege level changes,

lib/App/Dochazka/Common.pm  view on Meta::CPAN

273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
of what she did during the interval) and a C<remark> (admin remark).
 
For details, see L<App::Dochazka::REST::Model::Interval>.
 
 
=head2 Lock
 
In Dochazka, a "lock" is a record in the "locks" table specifying that
a particular user's attendance data (i.e. activity intervals) for a 
given period (tsrange) cannot be changed. That means, for intervals in 
the locked tsrange:
 
=over
 
=item * existing intervals cannot be updated or deleted
 
=item * no new intervals can be inserted
 
=back
 
Employees can create locks (i.e., insert records into the locks table) on their
own EID, but they cannot delete or update those locks (or any others).
Administrators can insert, update, or delete locks at will.
 
How the lock is used will differ from site to site, and some sites may not
even use locking at all. The typical use case would be to lock all the
employee's attendance data within the given period as part of pre-payroll
processing. For example, the Dochazka client application may be set up to
enable reports to be generated only on fully locked periods. 
 
"Fully locked" means either that a single lock record has been inserted
covering the entire period, or that the entire period is covered by multiple
locks.
 
Any attempts (even by administrators) to enter activity intervals that 
intersect an existing lock will result in an error.
 
Clients can of course make it easy for the employee to lock entire blocks
of time (weeks, months, years . . .) at once, if that is deemed expedient.
 
For details, see L<App::Dochazka::REST::Model::Lock>.