Setting IsEditable = false for an element disables the save / close button, but does not save the button?

Question

I developed a data extender class that acts on the GetItem and CheckOutItem commands to do some validation for a particular business, to determine if the user should have access to change the item or not (mainly if he passed the initial author task in the workflow , no one can edit it. By default, Tridion allows “reviewers” ​​to edit this element in the workflow, which does not matter in our business).

I am relatively confident that this worked at some point, but now no. I study what could change, but I thought I would ask here if anyone has an idea.

If the item cannot be modified, I set the IsEditable attribute to false. This actually disables the Save and Close button and the Save and New button, but for some reason the Save button is turned on. I do not quite understand why there might be a difference. (I'm looking for someone to somehow press the save button, but I don't see it being done). Any thoughts on how the “Save” button will be turned on when others aren't?

Thanks for any suggestions,

~ Warner

public override XmlTextReader ProcessResponse(XmlTextReader reader, PipelineContext context) { using (new Tridion.Logging.Tracer()) { string command = context.Parameters["command"].ToString(); if (command == CHECKOUT_COMMAND || command == GETITEM_COMMAND) { XmlDocument xmlDoc = ExtenderUtil.GetExtenderAsXmlDocument(reader); XmlNamespaceManager nsmgr = new XmlNamespaceManager(xmlDoc.NameTable); nsmgr.AddNamespace("tcm", Constants.TcmNamespace); try { //is this a page or component? XmlNode thisItemNode = null; thisItemNode = xmlDoc.SelectSingleNode("//tcm:Component", nsmgr) ?? xmlDoc.SelectSingleNode("//tcm:Page", nsmgr); if (thisItemNode == null) return ExtenderUtil.GetExtenderAsXmlTextReader(xmlDoc); // need to impersonate system admin in order to get workflow version of item later Session sessionSystemAdmin = Util.SystemAdminSession; XmlAttribute idAttribute = thisItemNode.Attributes.GetNamedItem("ID") as XmlAttribute; //if ID attribute is null, we don't have the actual object being used (just a referenced item. so, we'll ignore it) if (idAttribute != null) { string itemId = idAttribute.Value; VersionedItem tridionObject = Util.ObtainValidTridionIdentifiableObject(sessionSystemAdmin, itemId) as VersionedItem; //logic has been moved to separate method, just for maintainablility... //the logic may change when workflow code is finished. bool allowSave = IsItemValidForEdit(tridionObject, nsmgr); if (!allowSave) { //not the WIP ("author") task... make item read-only Logger.WriteVerbose("setting iseditable to false for item: " + itemId); XmlAttribute isEditableAttribute = thisItemNode.Attributes.GetNamedItem("IsEditable") as XmlAttribute; isEditableAttribute.Value = "false"; } } } catch (Exception e) { Logger.WriteError("problem with get item data extender", ErrorCode.CMS_DATAEXTENDER_GETITEM_FAILURE, e); } return ExtenderUtil.GetExtenderAsXmlTextReader(xmlDoc); } else { return reader; } } } 

Answer 1

The solution is to really look at the whole solution and it’s absolutely positive that no one has missed something recently, that the mess with the “Save” button magically resolves it behind the scenes. I re-edited the code to show how I originally received it. And it really works. It will disable saving, saving / closing, saving / new buttons and canceling all fields. I'm sorry that I spent time on Frank. Hope this here for historical purposes may come in handy for someone else with similar requirements in the future.

Answer 2

Most of the Tridion GUI probably bases the parameters that it represents on the so-called Allowed Actions. This is a combination of the Allow and Deny attributes that are present in list calls (if required) and the XML element.

So, at least you will need to remove the CheckIn and Edit action from the Allow attribute (and maybe add them to the Deny attribute). If you look at the Core Service documentation (or any other Tridion API documentation: these values ​​have not changed for a long time), you can find an Enum called Actions that contains possible actions and their corresponding values. The Allow and Deny attributes are simply the addition of these numbers.

In the CheckIn action, I mention number 2 , Edit is 2048 .

---

Update :

I have a small command line program to decode AllowedActions for me. To celebrate your question, I quickly converted it to a web page where you can find it here . Below is the main workhorse and shows how you can decode the number and how it can be manipulated. In this case, this is all subtraction, but you can just as easily add the allowed action by adding a number to it.

 var AllowedActionsEnum = { AbortAction: 134217728, ExecuteAction: 67108864, FinishProcessAction: 33554432, RestartActivityAction: 16777216, FinishActivityAction: 8388608, StartActivityAction: 4194304, BlueprintManagedAction: 2097152, WorkflowManagedAction: 1048576, PermissionManagedAction: 524288, EnableAction: 131072, CopyAction: 65536, CutAction: 32768, DeleteAction: 16384, ViewAction: 8192, EditAction: 2048, SearchAction: 1024, RePublishAction: 512, UnPublishAction: 256, PublishAction: 128, UnLocalizeAction: 64, LocalizeAction: 32, RollbackAction: 16, HistoryListAction: 8, UndoCheckOutAction: 4, CheckInAction: 2, CheckOutAction: 1 }; function decode() { var original = left = parseInt(prompt('Specify Allow/Deny actions')); var msg = ""; for (var action in AllowedActionsEnum) { if (left >= AllowedActionsEnum[action]) { msg += '\n' + action + ' ('+AllowedActionsEnum[action]+')'; left -= AllowedActionsEnum[action]; } } alert(original+msg); }