todo access issue

[fengyedou]

I for redmine admin account, all are ok, but if I logged into redmine as a common user, tested like below, there are 2 issues. I set the common user role has such acess(by the way, even if delete todo lists, delete todos are selected, result is the same)
View todo lists
Create todo lists
Update todo lists

Create todos
Update todos

1.It can create todolist, but cannot adding a todo item into the list.There is message:server returned an error, check console for more information.
For we set the description, start date, planned completed date as mandatory field when creating a task, but from creating todo, the 3 fields are not mandatory.

-----> I think if there is no plan to change the design of this plug-in much, maybe it is suggested to create a new tracker like todo not using redmine default trackers, and make sure the new tracker only requires issue title mandatory, others are not.

2.Can close other member's todo item. I think one only can close his todo item.
-----> Now, it seems one can close other's todo. I think it needs to fix.

[fengyedou]

@haslinger, what is your opinion about the 2 issue described above?

[adamziel]

1. Can't help without stack trace (should be in console if you are using dev server or somewhere in server logs);
2. I think it's okay to have a possibility to close other people todos, at lest that's how it works on basecamp which inspired this plugin. If you don't want this behavior then just make it a policy in your team.

[fengyedou]

@azielinski ,can you explain more about what the idea is-----to close other people todos, I really have no idea of such case, just want to hear about your experience :)

[adamziel]

for example if more than one person is able to do a task, and someone other than assignee decided to finish it in a spare moment

[fengyedou]

I see， thanks.

[haslinger]

1. I would need the stacktrace too (/log/production.log is the file where it should be created, it's just a long error message, probably around 50 lines. As the real issue is often in the middle, please post the full trace here).
2. • It is interesting to see the completely different thoughts and usecases. We managed the "privacy issue", in that way: Each person involved gets a private project and if tasks/tickets/whatever shouldn't be seen, the person can put them there. So I never saw the need ...
   • technical note: in the admin it says "delete todos" and not like in the tickets '''edit own notes''', so it behaves as stated
   • BUT: I looked in the code into the authorization check which checks for privacy of the associated issue (sorry, i always called them tickets, it's called issue in Redmine). If I read that correctly, then if the issue is private only the creator and the assigned_to user can change the todo_item. Btw.: I couldn't find the checkbox in the issue for setting it private in the beginning - the user has to have permission "Set issues public or private" in issue tracking. (Conclusion: set the issue to private and you have what you want.)

[fengyedou]

@haslinger ,it is great of your detailed share about your thoughts, I think set issue private will meet our needs,

-> for us, we are involved in one project or one team, and each person has many issues to do in a day, it can use like a memo, to record each one's daily ticket, if he wants to share with others what he wants to do today, he needn't to set it private, we will make a team policy to tell each one if you are not involved in other's ticket, plz donot update. Just for view.

-> If one wants others invisible from his tickets or avoid wrong operation by others, he can set his tickets private, it is decided by team member, no strict rule.

In a word, we take todolist as a personal daily todos for a departement, and a team shared todos for a project.

:)