I can see that "Tasks" are available for time entry in Timesheet screen till the weeks that belong to the timebox of the associated "Iteration" and it is ok. But if a "Task" status is "Closed" then also Time entry is possible against the Task which is not logical. Can restriction be imposed on this?
Hi everyone! Just wanted to let you all know that our latest release contains a feature allowing you to restrict time entry on closed items. You can learn more on our blog post here.
I'd like to get your thoughts on the feature so would really appreciate if you could take 2 minutes of your time to fill out this 3 question survey.
Thank you in advance and happy tracking!
It's planned later this year: https://support.7pace.com/hc/en-us/articles/360000233723-Feature-Roadmap it is a part of Rules and permissions.
Could you please provide your feedback on this case:
I have a Task item, it is closed and already has some time tracked on it. It turns out that I've logged incorrect time and would like to fix time record. Will it be possible?
So the questions are:
1) Should we forbid any time manipulation with closed items?
2) Should we forbid only ADD/track of time, but edit operation of already existed tracks is allowed?
3) Should "Closed/Removed" state be hierarichally checked (if Task is not closed, but direct parent is closed)?
In my understanding, time ADD/EDIT should NOT be allowed against “Closed” work items.
Now to resolve your query, I think there can be an option (check box) in the Settings page like “Allow Time Entry for Closed Item”. This should be unchecked to restrict user to entry time against “Closed” items.
Now someone has made an incorrect time entry against an work item. The work item is marked later as closed and after that the incorrect entry is found out. In this situation, the above mentioned check box can be ticked temporarily by the administrator/global approver so that the person can rectify the incorrect entry. Once done, again the check box needs to be unchecked.
I think in this way we can manage flexibility.
Additionally, it will be great if restriction to enter time against work item type can also be made available. This has already been clarified previously by Magnus Schroder.
Thanks, I'm in the designing process of this feature, so all feedbacks are very appreciated
>In this situation, the above mentioned check box can be ticked temporarily by the administrator/global approver
And what if it is a large company (200-500 users, or even large)? In such a situation, it could be an annoying problem (admin will switch this checkbox several times a day).
1) The solution could be 2 checkboxes (one to restrict only adding time, second to block also editing). But it will look like a mess, so I don't like it.
2) Another solution is to reopen Item, edit time entry, close Item again. But it is also not the perfect solution.
3) Any other solutions?
And I would like to check your feedback on: Should "Closed/Removed" state be hierarchically checked (if Task is not closed, but the direct parent is closed)?
>restriction to enter time against work item type
yes, it is also on my desk, but I almost have no questions on it and let's discuss it not in the current thread :)
My recommendation is that the list of selectable items on the time record should be managed by a setting, e.g. Allow time to be recorded against these statuses" - the required Statuses will be selected by the Organisation.
Excluding "Closed" "Done" etc from the Allowed list will exclude them from the list of available Work items. If there is a need to record time against an excluded item simply change it's status, temporarily, in DevOps. I believe this will simplify the approach/Solution for 7Pace.
I like the recommendation about the list of selectable item on the time record. But I don't like the approach of change status of items just to book time.
I'd prefer a role based solution like administrators should be able to book time on closed items. So users who approve the booked time of the employees of a company are able to add / move time to closed items if necessary.
About the hierarchy: It shouldn't be possible to close a story when one or more children are still oben. Or do I understand something wrong? For me it makes no sense to close a parent and leave the child open.
First of all, thank you for your ideas, they're really valuable for us.
Claudia, great idea about the role-based solution. Regarding the hierarchy and parent-child states dependency - it's not a part of our product, we can't handle it. You'd better ask DevOps support about it.
Catherine, good wish about automaton. We're not sure it's possible, because we need some special integration interface by DevOps to make it notify 7pace Timetracker about the state changes. We'll investigate this possibility.
Nico, this feature is in our year plan. It's not exactly our priority now, we have some other features to do before. But it's planned to be implemented later this year. This is going to be a part of the Rules feature.
In our case, actually we have plans to leave the completed project in TFS/VSTS with Read Access for employees. In that case, they are able to enter timesheet against the tasks in those projects by mistake. Would like to check with you guys on possibility of providing option for this.
We close tasks as the user stories are scheduled for release so making it immediately impossible to enter time against a task after it is closed will create issues fir time entry in weeks when we are scheduling releases and closing tasks. However, if the closed tasks are locked for further time entry when the timesheet is locked, that could work, as the timesheets will not be locked until after the time is entered for the week within which the task is closed.
It seems to me that this would not be a huge programming ask and my company would really like to see this added to your feature update timeline.
It's coming up on a year when some control over locking out time logging against closed items was in the "year plan." Is there any update to having this happen in some way? Jo (in post above) seems to have proposed a good compromise. Almost anything would be welcome instead of leaving items open for time entry forever.
thank you for reaching out. We had some shifts in priorities and haven't got around working on this yet, unfortunately. This is now a candidate for Q3 and I'm hoping to get internal agreement on this soon. I'll confirm on here once we have a definite ETA.
Product Owner - www.7pace.com
from the discussion i can see, that different users handle work item status differently, so why not throw in a slightly different approach:
Instead of using the work item status for blocking time registration, why not create a completely new work item field called "blocked for time registration". In case this field is set, registration of additional time will no longer be possible.
To satisfy the initial requirement of this post, a setting "select work item status for time registration blocking" could provide the connection between blocking and status change (triggering an automated update on field "blocked for time registration" when work item status changes). This would allow to enable blocking even with customized work item status.
For those of us, who block disconnected from any status change, leaving this parameter empty would give us full control.
"blocked for time registration" would mean for me: from this point in time, registering time on this work item should be blocked regardless. This involves making sure before blocking, that all related time has been registered.
It does not mean: approval for prior registered time needs to be blocked. Approval of already registered time should be possible even for blocked work items (however I could as well delay my blocking until all time has been approved).
I completely agree with Stephan point of view; a simple "Prevent time entry against closed items, after [ xxx ] hours." would allow quite easily, without breaking any UI or app, to have some different rules for different organisations.
For example, prevent entries after 24h on closed tasks, so a user could add time the same day, but not a week or a month after.
In our case, preventing time entry against Closed Tasks is not easy, because some developers prefer to enter their time in the timesheet at the end of the day, so Task might already be closed.
This was implemented and that is great. I have been using it. There are other work item types that do not use Closed as their final status, but should be considered like a closed item for time tracking purposes. The work item types (WITs) I would like to see a time tracking lock-out are the following:
- Shared Parameter uses Inactive (and Active). Time tracking should be locked out for Inactive.
- Test Plan uses Inactive (and Active). Time tracking should be locked out for Inactive.
- Test Suite uses Completed (and In Planning and In Progress). Time tracking should be locked out for Completed.
Please sign in to leave a comment.