Profuse Perpetual Pointless Pernicious Permission Problems

I’ve been working with M2M for nearly 12 years, and they’ve made very little progress with permissions. I’ve placed several change requests regarding permissions, which have gone unheeded. Smaller companies with only a few M2M users will probably not relate to some of these issues, but they become major problems when you administer 40+ users and multiple companies, like I do.

What are the Problems?

  1. M2M does not provide a way to tie your Active Directory structure to your M2M account. Yes, if you use the same usernames in M2M as AD (assuming none of your AD names exceed 10 characters), you can automatically log in. However, the admin must manually set permissions for each person. There are no groups in M2M with regards to rights, so you have to assign each person individually. M2M suggests that you create a sample user for every job in your facility and copy permissions from those accounts. For example, you might have user accounts such as “SalesAdmin”, “SalesMngr”, etc. Those accounts would act as your base permissions account for those job positions. However, when the Sales Administrators’ permission requirements change, this process is even more tedious. You must add the permission to the base account “SaleAdmin” and then manually copy the rights to each Sales Administrator afterward. Exactly how does this accomplish anything?
  2. Each new report must be assigned manually per employee as well. Every time you create a Sales report for your Sales Administrators, you must add that permission to each one.
  3. Setting up a practice company is tedious because rights have to be given manually per person. Why isn’t that an option when creating a new company? More on this later as I think a friend of mine has created an application to accomplish that very task, and I’ll share it with my readers in a future post.
  4. The permissions tables are encrypted (username) so you can’t write custom reports nor create a program to automatically manage permissions.
  5. New users have root control of M2M by default and this is a terrible security policy. I can’t tell you how many times I’ve run the Permission Report and seen that the new guy could ruin us because another admin (I would never make such a mistake right?) forgot to limit his rights.
  6. Speaking of the Permission Report, it is awful as well. It takes forever to run, and it’s very inflexible. For example, I want to be able to run the permissions report per screen only for those people who have deletion rights. The standard report doesn’t allow this. Therefore, I export them and import them into an access database and use a Crystal Report to summarize them per screen.
  7. ”Hidden” screens can be a problem as well. For example, let’s assume your Sales Administrator role is to add new sales orders to the system. So, you give them Add and Edit permissions to the Sales Order (SO) screen. The user re-starts M2M for the permissions to take effect and then come to you with the following error:
    SO Add
    Not only do you have to provide permissions to the SO screen, but you have to provide permissions to screens such as SOADD and SOCHNG as well.
  8. Speaking of Sales Orders, they are like many other documents in that you cannot give users permission to delete line items, but not entire master document. This is a hassle because I’d rather inconvenience the user as little as possible. A disgruntled employee can really hurt you with deletion permissions.
  9. Why can’t users change their own password? This is a huge security problem that all passwords are assigned by the M2M Administrator. This problem has actually been addressed in Version 6.0.
  10. Finally, and this is a small issue, but if you try to remove rights to a certain screen and you start with View, you will receive the following:
    This goes back to blog post about M2M Errors. If M2M knows what I need to do, why doesn’t it simply do it?

What do you folks think? Have I been too harsh? What problems do you have with the current permission structure?

11 comments to Profuse Perpetual Pointless Pernicious Permission Problems

Leave a Reply




You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>