Hi M-Files and community,
As we are heading now to introduce multiple approvers in different workflow states for one of use cases we currently developed, we have start using heavily assignment concept. Usually we would prefer assigning directly document to single user but as this is not possible in case of multiple users, we need to switch to use assignments.
To enable "Assigned To" users to approve/reject assignments, we have enabled for those users read/write permissions using Document.<MyApprover>.MfilesUserId. Those users get correctly edit permissions. But we face following problems and challenges:
- Those users can add an additional user for an assignment as they have edit permissions on "Assigned To" metadata. This is really bad as we want to control assignment object. Through this they can add any user there to get assignment. Those people get assignment without link to document. Very confusing and actually not what they should do at all! The strangest thing is that they can add additional approver but can not remove it afterwards! In that case M-Files throws access error. Very strange behavior.
- Even users who just see (read-only access) to assignment can edit boxes beside names of "Approved To" users. He/she can not save it and get access error but this shows that these checkboxes seem to be completely independent from "Assigned To" metadata and that only pop-up event is bound on clicking on them. Good thing is that he/she can not change it at least. But this is far away from modern usability nowadays.
- This one is actually unacceptable: let's say we send assignment to 2 approvers, first approver selects his/her checkbox and tries to select checkbox of his/her colleague. He/she get correctly access error as he/she should not change "Assigned To" box of other user. Again completely technical error, user friendly but at least there is some protection. But if first approver approves it, the second one can change selection of the first one and overwrite decision of the other user! This is definitely big security risk and should not happen. Then the first one can change it from the second one and vice versa. This seems to occur after one of approvers make decision (approval in our case) and other sees his/her decision. This is really not good as we lose completely security protection. At least history is intact and users can see that their fellow colleagues actually uncheck their decision :).
- The last one is even the worst I find it: let's say both approver approve assignment and we have functionality on workflows step that when all approvers approve assignment, it goes automatically to next workflow step (actually great feature!). That works well. But one of approvers can come to an idea to go back to assignment and reject it without problem even though document has been already sent to next state! This jeopardize the whole concept of assignments and automatic transitions when all users approve it. Why is this assignment not read-only afterwards? Do we need to make it read-only somehow?
I've never gone so in depth with testing but after 2 good sessions with colleagues we were able to find many strange behaviors.
How do you see this behavior? Is this assignment behavior of assignments? Do you have experienced similar, have you solved those problems somehow?
This comes again to the point that I've written in multiple threads about assignments: why not rendering 2 buttons for those approvers: "Approve" and "Reject"? When approver clicks on button, M-Files could update checkbox beside "Assigned To" for specific user (approve/reject). "Assigned To" and those checkboxes should be read-only.
Today I have set with a colleague who never have seen M-Files before and I asked here to try to approve assignment. She has searched for buttons all around the place, then she started messing around with checkboxes and she then suddenly added new approver as "Assigned To" is editable. I was astonished. This is really not intuitive and user friendly at all. People are used to have buttons. Same for workflow transitions.
I understand that this must be technical problem for M-Files and native desktop client but it must be some way to improve this usability.
It would be really great if this can be addressed and improved.
If you need screenshots, example etc. I can provide those as well for reproducing.
All the best to all you.