Individual Data Screens

Objective / Overview

openPETRA contains several screens which allow recording of data for a Partner of Partner Class PERSON - that is a Partner who is a Worker of an organisation. These screens are called 'Individual Data Screens' and the objective of this Project is to create such screens. Some of these screen allow editing of one record only, others allow for CRUD (Create, Read, Update, Delete [1]) operations.

Example: TODO

Notes:

• The corresponding Bug (=Feature Request) is TODO.
• The Bazaar Branch in which the development is to happen is called TODO.

Desired Outcome

Adding a few Individual screens to openPETRA and in the course of doing that

• learning about the client-side project structure
• learning about our screen definition files (YAML files)
• getting to know the openPETRA database structure documentation
• getting to know the WinForms Generator

For details about what is expected of the screens that are produced refer to section 'Approval of Functionality and Program Code' below!

Solution

Follow the steps on the TODO wiki page for each of the screens.

TODO You can read the Overview once, then skip Step 1 and the first sections of Step 2 and start straight at the section under the heading 'Copying the screen definitions file' since the information which you need for copying an existing screen definitions file is already given here.

Example Screen

ChristianK created two example screens, 'Special Needs' and 'Personal Languages', which represent the single record and CRUD screen types. Those can be taken as a blueprint for every new screen of that screen type listed below. Go to this wiki page TODO to see details about that.

Finding DB Tables Definitions

The definitions for the openPETRA DB Tables which are used in the screens can be found here.

Scope: Individual Data Screens List

Note: The column 'Complexity' is not of importance to you, but it is important for the openPETRA team to be able to assign easier screens to you as you get started.

Screen Name	Screen Type	Complexity	Database Table	Comment	Assigned To	Approved
Passport Details	CRUD	?	pm_passport_details		Thomas Wodarek
Personal Documents	CRUD	?	pm_document	(*5)	Andrew Kane
Previous Experience	CRUD	?	pm_past_experience	(*5)	Andrew Kane
Commitment Periods	CRUD	?	pm_staff_data	(*5)	Victor Norman
Job Assignments	CRUD	+	pm_job_assignment	(*5555)	Andrew Kane
Progress Reports	CRUD	+	pm_person_evaluation	(*6666)	Victor Norman
Personal Skills	CRUD	?	pm_person_skill	(*4) - as in pm_special_need
Personal Data	Single Record	?	p_person	(*4) - as in pm_special_need	Thomas Wodarek
Emergency Data	Single Record	?	pm_personal_data	(*4) - as in pm_special_need
Ability	CRUD	?	pm_person_ability		Thomas Wodarek
Local Personnel Data	User Control	?	p_data_label_value_partner

(9 Individual Data Screens)

Key to Comments

• (*1) = TODO.

• (*A1) = TODO.

Dealing With Errors When Saving Data

If you find that you get an error message when trying to save changed data in any Individual Data Screen, have a look in the Client Log file (U:\openpetraorg\log\PetraClient.log) to see the actual exception (at the very end of the file). The most common cause of getting a problem at that point is that a certain field that is specified in the DB is not on the screen, and that DB field has the Constraint 'NOT NULL'. This will prevent saving, as openPETRA doesn't assign anything, not even NULL automatically to such fields, since they are not on the screen. The solution for that is to have a Method called 'GetDetailDataFromControlsManual' in the ManualCode.cs file. You can find an example implementation for it in the file U:\openpetraorg\csharp\ICT\Petra\Client\lib\MPersonnel\gui\setup\AbilityAreaSetup.ManualCode.cs. If this is not applicable or still doesn't solve the problem of not being able to save changed data, ask ChristianK, who should be able to help you.

Approval of Functionality and Program Code

• Demonstrate the new Individual Data screen in openPETRA.
  • CRUD screen type:
    • Editing of existing records needs to work;
    • Adding of new records needs to work;
    • Deleting of existing records needs to work.
  • Single record screen type:
    • Editing of existing records needs to work.
  • If ComboBoxes are used in the screen: ComboBoxes need to show correct values.
  • Formatting needs to be correct in the Grid Columns and in the data entry fields.
  • Data in all the data entry fields needs to be saved and retrieved correctly.
  • Screen Layout should be similar to what it looked like in Petra 2.x, except if deviations are specified for a screen. (For CRUD screen Types: Layout applies to both the Grid Columns and the Details section).
    • Show the example screen to ChristianK and proof that the layout of the new screen follows the layout of Petra 2.x very closely (or follows the deviations specified).
• A check will be done to see if the instructions in the 'Comment' column of the table above were followed.
• The program code in the *.ManualCode.cs will be reviewed by ChristianK.