Problems with Assignments objects

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.

Dejan

  • Dejan,

    From what you've outlined it sounds like there should be some adjustments made to the specific assignment classes being used.  Normally the Assignment Object Type is hidden in the Admin console but you can right-click the Structure Hierarchy and 'Show All' which provides you access to view and update the Assignment object, create new assignment classes, etc...  The Assignment Classes are categorized as task types and approval types, specifying an Assignment Class as an Approval type provides the "Approve / Reject' check boxes you are looking for so I would recommend looking at utilizing an Assignment Class of this type.  Additionally, permissions applied to the assignment class should prevent edits to the Assignment, however, you might also consider implementing metadata card configuration rules to prevent your users from even being able to attempt adjustments, there is a setting available in the MCC behavior which allows you to set a property as read-only as part of a MCC rule and this prevents the field from even being selectable.   Regarding making Assignments read-only after completion, if you're using separate assignments, since they are their own object you can actually drive them through their own workflow!  This allows you to drive permissions to provide edit access to the pertinent fields while the assignment is open and then apply a read-only schema after completion by transitioning the assignment into a completed workflow state where those permissions are applied on the object.  These are at least a few items I thought of when reading your post, I'd be happy provide some additional pointers if you need assistance with any of these items.  

    Tom

  • Hi Tom, 

    We already use metadata card rules to control editing of specific fields on assignments (name, assignment description etc.) and it works well. We also control access on assignment object properly (only approvers can edit assignments, some other users have only read only access). This is verified and is correct when looking into NACLs on Assignment object. We also use "Approval Assignment" which provides Approve/Reject option. 

    Our problems are more related when multiple approvers are assigned to same assignment and issues they can cause one to other.

    To show more in details, I have created series of screenshots with explanations.

    After first approval, approvers can change each other decisions which is extremely problematic. Also one approver can approve for both of approvers after first round. This jeopardize the whole concept of assignments and introduce big security issue.

    I find this approach with checkboxes generally problematic. Why not using rendered buttons approve/reject based on the session of the user (and than updating metadata behinds LastModifiedBy and DateTime etc.)? This is so unfriendly and obviously error prone.

    Regarding making assignments read-only after moving it to next workflow step: well adding workflow on assignment object could be possible, but it seems to complicate assignment object even more. I don't understand why history assignment can be editable in the first place. It is so risky. Probably there we would need to think how to find previous assignment and set it read-only for all users (don't know if the API would support us on it). The workflow solution must be again somehow connected with document type specific workflow so we would need to move assignment into specific workflow when we reach next workflow step for the document.

    I find assignment very useful but unfortunately they seem to have certain pitfalls. It would be great when M-Files would invest some resources to re-design and improve this concept.

    Best regards,

    Dejan