locked
mysteriously permissions error RRS feed

  • Question

  • If I want to create a new incident and click "OK", the incident is created normally. No errormessage shows up.

    But if I click "Apply" before using the "OK" - Button the following error shows. No permissions to create an Incident. The Incident is created anyway but the errormessage shows up.


    Date: 28.08.2014 12:23:27
    Application:
    Application Version: 7.5.2905.0
    Severity: Error
    Message:

    Microsoft.EnterpriseManagement.Common.UnauthorizedAccessEnterpriseManagementException: The user domain\User does not have sufficient permission to perform the operation.
       at Microsoft.EnterpriseManagement.Common.Internal.ServiceProxy.HandleFault(String methodName, Message message)
       at Microsoft.EnterpriseManagement.Common.Internal.ConnectorFrameworkConfigurationServiceProxy.ProcessDiscoveryData(Guid discoverySourceId, IList`1 entityInstances, IDictionary`2 streams, ObjectChangelist`1 extensions)
       at Microsoft.EnterpriseManagement.ConnectorFramework.IncrementalDiscoveryData.CommitInternal(EnterpriseManagementGroup managementGroup, Guid discoverySourceId, Boolean useOptimisticConcurrency)
       at Microsoft.EnterpriseManagement.ConnectorFramework.IncrementalDiscoveryData.Commit(EnterpriseManagementGroup managementGroup)
       at Microsoft.EnterpriseManagement.UI.SdkDataAccess.DataAdapters.EnterpriseManagementObjectProjectionWriteAdapter.WriteSdkObject(EnterpriseManagementGroup managementGroup, IList`1 sdkObjects, IDictionary`2 parameters)
       at Microsoft.EnterpriseManagement.UI.SdkDataAccess.DataAdapters.SdkWriteAdapter`1.DoAction(DataQueryBase query, IList`1 dataSources, IDictionary`2 parameters, IList`1 inputs, String outputCollectionName)
       at Microsoft.EnterpriseManagement.UI.ViewFramework.SingleItemSupportAdapter.DoAction(DataQueryBase query, IList`1 dataSources, IDictionary`2 parameters, IList`1 inputs, String outputCollectionName)
       at Microsoft.EnterpriseManagement.UI.DataModel.QueryQueue.StartExecuteQuery(Object sender, ConsoleJobEventArgs e)
       at Microsoft.EnterpriseManagement.ServiceManager.UI.Console.ConsoleJobExceptionHandler.ExecuteJob(IComponent component, EventHandler`1 job, Object sender, ConsoleJobEventArgs args)

    Any Ideas?




    • Edited by Simon Eiden Monday, September 1, 2014 7:27 PM
    Thursday, August 28, 2014 10:28 AM

All replies

  • you are in a security role that has a queue filter, and your GroupCalcPollingIntervalMilliseconds is greater then the time it takes to click apply-ok. 

    when you try to read an entity from the database, the list of groups and queues that entity belongs to is compared to the groups and queues your security role grants you access to, and you are allowed to do the things that you are allowed to do. The counter of this is the fact that the groups and queues are not instantly stamped, but instead get marked in the background.  let me explain:

    When you create a work item, the in-memory copy that is on your computer behind the form is submitted to the database and written in. you still have an in-memory copy, which is why you can still see it. 

    on the other side, the submitted projection is merged into the database and a new entity is created to represent the work item. at this point, there are no groups stamped on this entity (queues are a special case of entity groups where all members are work items).

    sometime in the next GroupCalcPollingIntervalMilliseconds it will be "stamped" (for lack of a better term) with which groups that entity should belong to by executing the group selection rules and marking all of the entities with their groups. (Coincidentally, this is why this bug report is missing the point with style. )

    if you try to access this entity (i.e. read it with the refresh button, or write it with OK) before it's stamped with a group, then the access control engine will come up with the answer that you don't have any access. if you wait until it's stamped, you should have the correct access. 

    The fix for this is to try to use un-scoped roles as much as possible. this has the side effect of letting everyone who is charged with resolving tickets actually resolve those tickets. 


    • Edited by Thomas Bianco Thursday, August 28, 2014 2:34 PM better phrasing
    • Proposed as answer by Mickey Gousset Thursday, August 28, 2014 2:44 PM
    Thursday, August 28, 2014 2:31 PM