The word "allocation" means-
1. A share set aside for a specific purpose
2. The act of distributing by allotting or apportioning; distribution according to a plan

But when we are entering the actual work done, we doing neither of this. Therefore the name of the GUI should be changed to Real Work logging
(BTW the word "allocation" is used correctly in resource allocation to projects)

The 2 seem correct IMO.
The idea is to "dispatch" the real work, so to allocate on corresponding Acitvity, day by day.
It could be changed to Real Work Recording, but idea of "dispatching", "distributing" the work is lost.

Issue#2: The project allows us to enter more than 24 hours in a day, although the resource is configured as FTE=1.
(see attached screenshot, titled WorkDone-1)

Desired: Never allow entry of more than (FTE x 24) hours.
For example, if the resource has FTE=2, then do not allow entry of more than 48 (= 2 x 24) hours.
(It is physically impossible for the resource to put up those many hours!)

It is designed this way ! They is a control (sum is hilighted in RED if over the capacity of the resource) but no blocking.
This is designed this way to allow users to not dispatch work over the week (or the month) but enter all monthmy follow-up in one single day.
This is used on initialization, when including project that already has real work, to avoid to enter data day by day.

But the extra hours were added by mistake, so ProjeQtor should have ignored the last entry.

How do you expect that projeqtor guess it is a mistake (ProjeQtOr cannot re

Desired: When an entry is deleted, the GUI should revert to the originally assigned hours (in our case, 24 hours)

The word "allocation" means-
1. A share set aside for a specific purpose
2. The act of distributing by allotting or apportioning; distribution according to a plan

But when we are entering the actual work done, we doing neither of this. Therefore the name of the GUI should be changed to Real Work logging
(BTW the word "allocation" is used correctly in resource allocation to projects)

The 2 seem correct IMO.
The idea is to "dispatch" the real work, so to allocate on corresponding Acitvity, day by day.
It could be changed to Real Work Recording, but idea of "dispatching", "distributing" the work is lost.

Issue#2: The project allows us to enter more than 24 hours in a day, although the resource is configured as FTE=1.
(see attached screenshot, titled WorkDone-1)

Desired: Never allow entry of more than (FTE x 24) hours.
For example, if the resource has FTE=2, then do not allow entry of more than 48 (= 2 x 24) hours.
(It is physically impossible for the resource to put up those many hours!)

It is designed this way ! They is a control (sum is hilighted in RED if over the capacity of the resource) but no blocking.
This is designed this way to allow users to not dispatch work over the week (or the month) but enter all monthmy follow-up in one single day.
This is used on initialization, when including project that already has real work, to avoid to enter data day by day.

But the extra hours were added by mistake, so ProjeQtor should have ignored the last entry.

How do you expect that projeqtor guess it is a mistake (ProjeQtOr cannot read your mind - not yet)

Desired: When an entry is deleted, the GUI should revert to the originally assigned hours (in our case, 24 hours)

No, because in most cases actual behavior is best :
- I have 10 left, enter 7 (left is 3) and enter 6 as new left (I need 13 do execute the task)
- If I remove 7 (because it was entered on bad day), and want to keep 13 is needed...

Issue#1
I think the words logging or recording are much better!
We can even think of accounting. (In the sense of giving an account of how many hours spend in which task)

Issue#2
Yes, I agree: When the project team has to give an account of past days, they may not have kept a track, and it is best to let them enter total hours which will definitely exceed the daily FTE.

This is a beautiful trick, and hats off to the guy who thought of this!

Issue#3
I see what you mean!