Unexpected values in project tasks/activities
trendspotter opened this issue · comments
No crash this time, but confusing or useless data displayed to the user (although arguably the users may deserve it as they gave confusing or useless data as input :) )
Steps to reproduce:
- Create an organization filling in the required fields (name)
- Go to Projects -> Projects -> Create
- Create a project filling in the required fields (implementer, name)
- Go to Activities tab in the newly created project
- Create an Activity filling in the required fields (none)
- Go to Tasks tab
- Click on Create Task
- Observe that the activity is represented as a number in the activity dropdown
- Create a task filling in the required fields (description)
- Reopen the task, change its activity and click on Save
- Reopen the task again and observe the comment which reads "Id changed from 1 to 1"
Problems:
- Is it expected that the activity description is not mandatory?
- Is it expected that an object with empty field gets represented as the id of the object?
- a) Is it expected that the activity modification isn't logged in the comment? (this happens even with meaningful data in the activities)
b) Is it expected that the id change is logged even when the id hasn't been changed? (this happens even when nothing is changed and just Save is clicked)
1 and 2 may be deliberate choices, but at least 3 seems like an actionable bug.
@problem 2: Yes, it is a deliberate fallback that an object where the relevant fields for representation (e.g. name) are empty is represented by its ID instead. That is to make sure that they can still be distinguished - specifically in selectors.
However, fields used for reference representation should normally be mandatory (although that does not mean the user has to fill them in - they could just default to something meaningful).
An empty activity description makes very little sense, so that field /could/ be mandatory.
a) the activity is not a field in the task table, and therefore the change is not detected by the change logger. The purpose of the change logger is though to allow tracking of workflow-relevant changes of the task - and the activity is not workflow-relevant. Hence, this miss is acceptable - and yes, expected.
b) is a bug indeed.
An empty activity description makes very little sense, so that field /could/ be mandatory.
Unless it's just used as a link table, which may well be the case somewhere
Additional explanation for 3a) - the "log" trail has the following use-case: the person managing the task and the person executing it are oftentimes different persons.
So, when either of them changes anything in the task that should affect what the other one does with the task, then obviously the other one must be able to see that something has changed, what has changed and when it has changed - otherwise the change may go unnoticed and thus have no effect.
Therefore, any workflow-relevant changes (task details, status, priority) shall automatically be shown in a comment trail underneath.
When the activity categorization is changed, however, this has normally no bearing for this exchange - as it is typically only relevant on the managing side? If there is a use-case where it is relevant, I think it can be added - but I don't think it needs to be there by default.
Unless it's just used as a link table, which may well be the case somewhere
Apart from location, there is no meaningful link in project_activity (I think project_location is used instead?) - my gut feeling is that activities are always explicit. But that's why I said /could/.
I think maybe distributions in 1 model
...in which case it could still be made mandatory in the interactive form (prep).
But then again, I must say that leaving the description empty - out of all fields for activities - doesn't sound like a common/deliberate interactive user behavior. If it were to happen accidentally very often, then we could consider making it mandatory there - but I wouldn't call it an outright bug.