The job interview model is not in the DMRB - it was something we created
internally. The current model has some flaws that are easily fixed, but
it is fundamentally correct, and it can be expanded to accommodate more
data. For example, there might be information about the interview that a
government agency requires for reporting.
-Adrian
On 7/27/2012 9:52 AM, Jacques Le Roux wrote:
Yes but Adrian has some points:
A job interview:
1. Has an estimated start time and end time
2. Has an actual start time and end time
3. Can be cancelled, postponed, or rescheduled
4. Includes a number of parties in various roles
5. includes a number of communication events
6. Has a location
7. Has a status (the outcome of the interview)
1+2) Time, duration, (both estimated and actual)
3) status
6) location,
7) result
It's not as simple as a phone call (which could though have also the
same attributes, but will then be a conf call) or mail exchange (etc.)
Disclaimer: did not had a chance to check the data model nor re-read
the book at this stage
Jacques
From: "Pierre Smits" <pierre.sm...@gmail.com>
Adrian, Hans,
Thinking a bit more about the jobinterview, I would say that it a
specific
type of survey (like a customer satisfaction survey or employee
satisfaction survey). For that, some functionalities are already
available
in the Content application/solution.
But a jobinterview involves a higher level of privacy and security.
Nonetheless, an interview (or a survey) is exchanging communications
between multiple parties.
My 2 cents.
2012/7/27 Hans Bakker <mailingl...@antwebsystems.com>
Adrian,
Just telling me it should stay, is not enough, you have to provide
reasoning for that.
my opinion is that a job interview is just a communication event of
the
new type 'Jobinterview' with the roles already there. A job
interview can
then already relate to other communication events of type email or
others.....
Hans
On 07/27/2012 01:46 PM, Adrian Crum wrote:
I agree that employee leave belongs in the Work Effort entities.
The JobInterview entity should stay, but its model needs to be fixed.
There should be a JobInterviewRole entity that connects the
JobInterview
with Party, then the jobIntervieweePartyId and
jobInterviewerPartyId fields
can be removed. We can also add a JobInterviewComm entity that
connects
JobInterview to communication events.
-Adrian
On 7/27/2012 7:17 AM, Hans Bakker wrote:
Replacing them with the indicated entities......
On 07/27/2012 12:27 PM, Adrian Crum wrote:
I don't understand the question. Are you proposing removing those
entities?
-Adrian
On 7/27/2012 4:42 AM, Hans Bakker wrote:
we intend to reduce the number of entities in HR:
EmplLeave
EmplLeaveReasonType
EmplLeaveType -> workeffort+related-entities so it also appears on
the calendar
JobInterview
JobInterviewType -> communication event and related entities
any comments or suggestions?
Regards,
Hans
