Feature #8554
closedForbid irreversible mark modifications for users with weak access
0%
Description
Let's introduce one quite simple but important change in Klever version:0.3.
Namely, at the moment job experts can do everything with all marks. In particular, they can delete either some mark versions or completely delete marks. Indeed this isn't necessary at all, since if one wants to clarify some mark, one should modify it rather than to delete it and to create a new mark instead. Besides, I suppose to forbid deleting mark versions except ones created by their authors. This can result in inability to delete own marks when other users modified them. But I suppose that marks deletion is almost a meaningless operation. Let's powerful managers will resolve all such conflicts and clean up trash if so.
Updated by Vladimir Gratinskiy about 7 years ago
At the momment only global Managers and Experts and authors of last mark version can delete mark. Users can't remove first and last version of mark. So author of mark is always known. But if someone modified the mark, the mark can be completely changed, so it is the same operation as to remove mark and create new one. So auhtors shouldn't have an access to remove mark changed by manager for example.
Updated by Evgeny Novikov about 7 years ago
Vladimir Gratinskiy wrote:
At the momment only global Managers and Experts and authors of last mark version can delete mark. Users can't remove first and last version of mark. So author of mark is always known. But if someone modified the mark, the mark can be completely changed, so it is the same operation as to remove mark and create new one. So auhtors shouldn't have an access to remove mark changed by manager for example.
Now this seems strange that an author of a last mark version can delete the mark. Indeed he/she can mistake and then remove other efforts. It looks to be better if just an author of all mark versions can delete the mark.
Besides, this likely will enable to remove a last mark version which is often useful.
Updated by Vladimir Gratinskiy about 7 years ago
Evgeny Novikov wrote:
Vladimir Gratinskiy wrote:
At the momment only global Managers and Experts and authors of last mark version can delete mark. Users can't remove first and last version of mark. So author of mark is always known. But if someone modified the mark, the mark can be completely changed, so it is the same operation as to remove mark and create new one. So auhtors shouldn't have an access to remove mark changed by manager for example.
Now this seems strange that an author of a last mark version can delete the mark. Indeed he/she can mistake and then remove other efforts. It looks to be better if just an author of all mark versions can delete the mark.
If someone change the mark nobody can delete it? Cool.
Besides, this likely will enable to remove a last mark version which is often useful.
I'm not going to do it as users can select needed version and apply it.
Updated by Evgeny Novikov about 7 years ago
Vladimir Gratinskiy wrote:
Managers can delete everything. In other cases users need to resolve conflicts. Anyway, marks should be deleted just in two cases:Evgeny Novikov wrote:
Vladimir Gratinskiy wrote:
At the momment only global Managers and Experts and authors of last mark version can delete mark. Users can't remove first and last version of mark. So author of mark is always known. But if someone modified the mark, the mark can be completely changed, so it is the same operation as to remove mark and create new one. So auhtors shouldn't have an access to remove mark changed by manager for example.
Now this seems strange that an author of a last mark version can delete the mark. Indeed he/she can mistake and then remove other efforts. It looks to be better if just an author of all mark versions can delete the mark.
If someone change the mark nobody can delete it? Cool.
- If there are duplicates.
- If they are too outdated and there likely won't be associated reports.
Both cases are manager responsibilities.
Besides, this likely will enable to remove a last mark version which is often useful.
I'm not going to do it as users can select needed version and apply it.
In many cases it is just required to remove n last mark versions. It isn't convenient to restore some old version and then delete n last mark versions excluding a new one. Moreover in such cases there is always an extra version that corresponds to restoring.
Updated by Vladimir Gratinskiy about 7 years ago
Evgeny Novikov wrote:
Vladimir Gratinskiy wrote:
Managers can delete everything. In other cases users need to resolve conflicts. Anyway, marks should be deleted just in two cases:Evgeny Novikov wrote:
Vladimir Gratinskiy wrote:
At the momment only global Managers and Experts and authors of last mark version can delete mark. Users can't remove first and last version of mark. So author of mark is always known. But if someone modified the mark, the mark can be completely changed, so it is the same operation as to remove mark and create new one. So auhtors shouldn't have an access to remove mark changed by manager for example.
Now this seems strange that an author of a last mark version can delete the mark. Indeed he/she can mistake and then remove other efforts. It looks to be better if just an author of all mark versions can delete the mark.
If someone change the mark nobody can delete it? Cool.
- If there are duplicates.
- If they are too outdated and there likely won't be associated reports.
Both cases are manager responsibilities.
Fixed in "bradge-access".
Besides, this likely will enable to remove a last mark version which is often useful.
I'm not going to do it as users can select needed version and apply it.
In many cases it is just required to remove n last mark versions. It isn't convenient to restore some old version and then delete n last mark versions excluding a new one. Moreover in such cases there is always an extra version that corresponds to restoring.
Deleting last version is not just "clearing trash" (as it was supposed to be). It is changing the mark including connections recalulation. And user should be redirected to mark's associations changes page.
Updated by Evgeny Novikov about 7 years ago
- Status changed from New to Resolved
Vladimir Gratinskiy wrote:
Evgeny Novikov wrote:
Vladimir Gratinskiy wrote:
Evgeny Novikov wrote:
Besides, this likely will enable to remove a last mark version which is often useful.
I'm not going to do it as users can select needed version and apply it.
In many cases it is just required to remove n last mark versions. It isn't convenient to restore some old version and then delete n last mark versions excluding a new one. Moreover in such cases there is always an extra version that corresponds to restoring.
Deleting last version is not just "clearing trash" (as it was supposed to be). It is changing the mark including connections recalulation. And user should be redirected to mark's associations changes page.
Let's postpone this minor issue. After you implemented testing unknown mark associations and after removing the most of error trace comparison functions, users will rarely need to revert mark changes.
Updated by Evgeny Novikov about 7 years ago
- Status changed from Resolved to Closed
I tested the feature and merged the branch to master in 7612c4cc.
Updated by Ilja Zakharov about 7 years ago
- Subject changed from Forbid irreversible mark modifications for users with week access to Forbid irreversible mark modifications for users with weak access
Updated by Vladimir Gratinskiy about 7 years ago
The problem still is not fixed. After the mark was changed the author of the mark can change it again and then remove all versions (except first and last) and then he can remove the mark as he is author of all versions again. I will allow to remove versions for its authors only (manager and global experts still will be able to clear all).
Updated by Vladimir Gratinskiy about 7 years ago
- Status changed from Open to Resolved
Already fixed in branch "bridge-access".
Updated by Evgeny Novikov about 7 years ago
- Status changed from Resolved to Closed
I didn't test this a bit tricky scenario. Now it works as expected. So, I merged the branch to master in 14843000.