Editing hire/fire table for an employee [duplicate]

Question

I need to create a HTML/JavaScript code to edit hiring/firing records for a given employee (the software receives a constant employee ID for the UI to deal with one employee at a time).

One employee may be hired and fired several times during the history of our company. (For example she may go to a parental leave and return to the work later.)

The table has the following fields:

• employeeid (the ID of the employee)
• hired (date)
• fired (date)
• firereason enum('fired','left','parental','vacation','sick','death')
• comment text

As you see there are a number of fire reasons:

• 'fired' (forced to be fired by the boss)
• 'left' (left the job by his own will)
• 'parental' (left for a parental vacation)
• 'vacation' (non paid vacation)
• 'sick' (sick leave)
• 'death' (death)

I want to present the list of pairs of hire/fire to the editor as a table, sorted by hire date.

Note that for the last hire/fire record fire date may be missing (null), if the employee for hired but not yet fired.

I am lost about more details how it should be presented and interacted.

---

After some additional thought I decided that it is best to present the information as a static (non-editable) table with "Edit" buttons in every row.

Now an additional question is arisen: Should "Edit" open a modal window above gray background or an additional row in the table? Which of these two variants is better? Also which buttons should be present in this additional row: "OK", "Cancel"? Can we switch to editing an other row without pressing "OK" or "Cancel"?

Answer 1

A modal is generally a good approach for following reasons:

1. User context is maintained
2. Adding and editing experience is the same

I am curious though, on why not do inline editing and auto-save ?

Answer 2

This is data which is quite sensitive. You shouldn't be able to edit any data, really. The only thing you should be able to do is add an overriding record. That obviously has a link back to the original incorrect reason, plus an explanation why the update was made.

The one obvious exception is that you can edit the "fired" data of a record which didn't have that yet. But it might be easier to manage the list as a list of all changes, so you can add "promotion" and "transfer" records as well. In that case, all records become immutable once created. Also, it makes it easier to deal with status changes such as "Sick leave"=>"disability" (a realistic sequence of events). With separate records, you just add another record, with a new date. Currently you can't have two "fire" dates.