I developed a data extender class that acts on GetItem and CheckOutItem commands to do some business-specific validation to determine whether the user should have access to modify the item or not (basically if it's past the initial "author" task in workflow, no one can edit it. by default Tridion allows "reviewers" in workflow to edit the item, which is a no-no in our business).
I am relatively certain this worked at one point, but now does not. I'm exploring what might have changed, but I thought I'd ask here in case anyone has an idea.
If the item can't be modified, I'm setting the IsEditable attribute to false. This does in fact disable the Save and Close button and Save and New button, but for some reason the Save button is enabled. I don't quite understand why there could be a difference. (I'm looking to see if someone extended the save button somehow, but I don't see that being done). Any thoughts on how the Save button would enable when the 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;
}
}
}
Most of the Tridion GUI probably bases the options it presents on the so-called Allowed Actions. This is a combination of the Allow
and Deny
attributes that are present in list-calls (if requested) and item XML.
So at the very least you will have to remove the CheckIn and Edit action from the Allow
attribute (and probably add them to the Deny
attribute). If you look at the Core Service documentation (or any other Tridion API documentation: these values haven't changed in a long time) you can find an Enum called Actions
that hold the possible actions and their corresponding values. The Allow
and Deny
attributes are simply additions of these numbers.
The CheckIn action I mention is number 2
, Edit is 2048
.
Update:
I have a little command line program to decode the AllowedActions for me. To celebrate your question, I quickly converted it into a web page that you can find here. The main work horse is below and shows both how you can decode the number and how you can manipulate it. In this case it's all subtraction, but you can just as easily add an 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);
}
The solution is to really look over the entire solution and be absolutely positive that nobody snuck something in recently that messes with the Save button and is magically enabling it behind the scenes. I've re-edited the code to show how I initially had it. And it does work. It will disable the save, save/close, save/new buttons and make all fields disabled. I'm sorry that I wasted Frank's time. Hopefully having this here for historical purposes may come in handy for someone else with similar requirements in the future.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With