To Delete $Sources Categories or Not To Delete $Sources Categories?, that is the question. Specifically, should the ability to restrict or implicitly allow an action be hard-coded into the DAM client? Or should that fall to the realm of the permission framework in the DAM system? Recently, I think Canto overstepped a bit by trying to answer that for everybody. Back when Cumulus 8.5.1 came out there was a “bug” in the Desktop Client that prevented all users except for the Cumulus SuperUser to delete or rearrange/reorder $Sources Categories.
A $Sources Category, FYI, is more involved than simply being under the $Sources Category Tree. There are three distinct types of Source categories. Directory Category Mac, Directory Category Windows and URL Directory Category.
Canto told me via the bug ticket I submitted, regarding the resurgence of the $Sources Category delete “bug” in 8.6.x, they had several feature requests to prevent users from deleting categories that were of the “Directory” kind. Further, they had inadvertently implemented it early, in version 8.5.1, and removed it in 8.5.2 because it had been intended for version 8.6.0 all along. huh?
If any of that confused you, you’re in good company. The funny thing is I can’t find any reference to this “feature” in the 8.6.0 “what’s new” document or the release notes. For the sake of giving Canto the benefit of the doubt, let’s operate under the assumption that they really did mean to implement this feature (the way they said). And that the documentation omission about the “feature” was just a fluke in the documentation process that hardly ever happens. Yeah, let’s go with that. (Sure.)
How to undermine the Permissions Model in one easy step: put it in the client
Since we’re going with idea that “it’s not a bug, it’s a feature”, I think it only fair to examine how the feature was implemented. First, what type of feature is it? Well, I would classify it as a restriction of user action — in this case, preventing users from deleting a specific type of category. That sounds awfully like a permission, doesn’t it? To this date, permissions have never been hard-coded into the client, or none that I can find. But yet, this one is.
I know that it’s hard coded into the client because Canto had a patch “to restore the previous behavior” waiting in the wings when I put in my bug report. In addition to the new executable and library files, a new line has to be added to the client.xml file, <ns:SourceCategoriesReadOnly>0</ns:SourceCategoriesReadOnly> with the explanation that the ability to allow all users to delete Source categories will be implemented as a hidden feature in future releases.
The fact that a permission is now hard-coded into the client, even if there is a per client method of enabling or disabling it, undermines the core behind Cumulus’s strong permissions model.
The way it’s been so quietly implemented and at the client level brings up a lot of questions. Was this really a feature or was it a bug that had a happy result and they ran with it? Were the devs in a rush to implement it and as a result they forgot all about the permissions model in their product? Can we expect to see more hard-coded permissions being quietly implemented in the client? Was this a programming shortcut because it would have been too hard to do it right in the first place?
Here’s a better way to accomplish the same goal
The better way to implement this would have been to work with the existing permissions model. Offer up a new permission in Server Console for categories so that instead of just “Delete Item”, it’s broken down by category type: Normal, Related, Master, and then Source (Directory Category Mac, Directory Category Windows and URL Directory Category) categories. It would provide administrators more granular control and keep permissions where they belong: in the established model, abstracted from the client.
Did we really need this feature in the first place?
I’m not even convinced this feature was necessary in the first place. In a Cumulus Enterprise environment (or Workgroup with extended permissions module), the Cumulus Administrator has all the tools needed to restrict users from deleting items under $Sources without a “feature” to do it.
Category Object-level permissions
All you have to do is set the permissions you want for $Sources (while working in the All tab) and let Cumulus propagate those down to all the child categories, making sure you’ve enabled the option that sub-categories inherit permissions from the parent.
A permissions template may help in this process if you have a lot of users or groups to define the permission for.
Final thoughts
The whole thing seems weird. But, the only thing that makes sense is if the request came in from a customer who was using Workgroup and didn’t have the options to use permissions like I detailed above. So, Canto wrote it into the client. Which, I suppose would have been not so bad back in the days when there were Workgroup Clients and Enterprise Clients. Now that it’s just Cumulus Client, it leaves room for unintended consequences.
Regardless of how it came to be, I think we need to ask why there wasn’t any mention that the feature had been implemented in the first place. After all, hard-coding a permission into the client represents a huge departure from the established permissions model.
Implementing DAM in an organization is a daily exercise in Change Management and Knowledge Management. The last thing DAM admins need to deal with is a vendor working against them on those two fronts. It’s imperative that vendors communicate and document the heck out of things that represent a paradigm shift — like hardcoding permissions into the DAM client.
The post To Delete $Sources Categories or Not Delete $Sources Categories appeared first on DAMagedWorkflow.