give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "A moniker is a simple name provided for an objects that simplifies identifying specific object instances.  This concept was first used in Microsoft Object Linking and Embedding (OLE), and the Component Object Model (COM).      The DNN Services Framework was first introduced in DNN 6.2.  When creating web services with the Service Framework, it is common to require callers to provide the ModuleId and TabId as part of the web request header.  This requirement complicates the programming model since service endpoints become tied to their specific location in a website.  Modules are able to easily retrieve the ModuleId and TabId from the service framework as part of the initial module rendering.  However, this mechanism is not available for remote callers, where the UI rendering is not directly controlled by DNN.    In order to encapsulate this context data and to simplify the programming model for web services, we should introduce the concept of a moniker.  The DNN service moniker will provide a mechanism for mapping a simple name to a specific module instance.  This moniker can then be passed to a web service in place of the ModuleId, TabId or any other context data specific to a module.    The moniker should be implemented as an additional system TabModule setting. By default, the moniker will be composed of the page name, the module definition friendly name and the TabModuleId separated by /.  When composing the default moniker, all spaces should be replaced with dashes.  For example, if the Social Groups module was on the “Community” page with TabModuleId of 100, the default moniker would be “Community/Social-Groups/100”.      The default moniker implementation provides a human friendly method to identify the page and module being addressed and also a unique element to differentiate between multiple modules on the same page.  The core platform should expose a service endpoint that allows an application to query for monikers related to a specific module type that the current user has permissions to view.    When calling service endpoints that need a specific module context, the moniker will be included as part of the service call.  The service can then use the moniker to easily lookup any context for the module instance associated with the moniker.    *Developer Notes:*  The purpose of this step is to help the back-end to create the DNN context for the web API request. Therefore, it is not tied to any authentication mechanism (like JWT, Basic, Forms, etc.)    Injecting the moniker in the query part of the API request requires modifying all existing API’s that need to use this moniker  but is not feasible and requires making changes to existing core (which we want to completely avoid). What we need is a non-invasive method. One way in which this can be implemented is by adding a new vendor specific header in the request as an alternate way to using the {{TabID}} and {{ModuleID}} that are in use today. Assume we are going to use {{X-DNN-MONIKER}} for this purpose. An example of a full header would be:  {{X-DNN-MONIKER: John’s Blog}}    Before being able to use this feature, there is a need for an API that returns the various monikers associated with a specific module. Let’s say in an EVOQ Engage site if we need to find all the monikers that use the discussions module, say discussions (i.e., all tabs/pages that have the discussions module in them), we will send an API request that returns all of these monikers associated with discussion modules placed on various pages. This call may return zero, one, or more monikers.    There must be a consideration for user rights in every data returned from the API; no private data should be revealed to an un-authorized user."
Answer: 20046.0