In Rally, when you edit a Feature or User story or whatever item, and you want to set a parent for it - it opens a modal called CHOOSE A PARENT.
In this popup, you can search by TYPE.
My question is: how do you restrict or disable the field TYPE so that either you can only choose some types of parents and not all, or search for only one pre-selected type?
Screenshot of restricted list
Screenshot of disabled field
That TYPE field is merely a filter to allow you to more easily narrow down which artifact you're looking for. Unfortunately, it can't be restricted or disabled as it is driven by the object model and how artifact relationships are designed in Rally.
For example, User Stories are allowed to be parented to either Features or other User Stories. This is why you see both of those options in the dropdown. But in the case of Features, they are only allowed to be parented to Capabilities. Since there is only one parent type available, the field is automatically disabled because you have no choice.
Another example is Tasks. They can be assigned to User Stories, Defects, Defect Suites, or Test Sets. In this case, you'll see all 4 of these options in the type filter dropdown.
And again, these relationships are inherent to Rally's core design and therefore cannot be manipulated or disabled.
Related
I'm working on identifying accessibility issues with a database-driven web application. One of the features of this web application is that the user can open up a modal window and filter by data columns. I included a couple of images to show what this looks like.
This is incredibly hard to use with a screen reader, mainly because I can't figure out how to associate the relationship dropdown with the input field. If a user selects a relationship (equal to, not equal to, greater than, etc...) I need to let the user know that it's associated with the input field to the right of it. But, I don't even know what this would be called or what I would wrap it in. Can anyone point me in the right direction?
I've got three views set up for one profile. They were all set up several months ago, at roughly the same time. Of these three, two have data. Both of these have identical filters set up related to IP exclusions. One of these has slightly fewer hits/pagviews/etc. The third view has the identical set of filters, but no data (and has not since it was originally set up).
Has anyone experienced this before? I'm completely at a loss (again, NOT the filters) for root cause.
Thanks!
Are the filters listed in the same order for all the Views?
In the Admin Tab of Analytics, you can go to the Filters section of your Views and compare their order.
Otherwise, you could copy one of the View that has the expected data and incrementally add filters to it until it matches your intended use for it. In the Admin Tab, select a View's View Settings and click the Copy view button.
I want to add the logs for the requirement history for the changes in the requirement tracebility. Currently,the logs for the changes in the requirement tracebilyt are not being captured in the history section.
Is any code or API to make changes in the requirement tracebility visible in the history tab?
thanks
History is not maintained for requirement traceability in QC. What you can do, enable history for comment field from customization and change your qc workflow script such that it adds comment (i.e. added link/removed link with ids) when somebody changes anything in requirement traceability section.
you have to make the Related field history enabled and to do so, you have to have administration rights on the project.
then go to Tools>Customization>Project Entities> Test Cases
then find your field in either the System Fields list or the User Fields list.
select the target field, in the RHS you will see the field properties and one of the properties is History Enabled. check that option and Save then Hit Return.
Log out of the project and re-Login.
now changes to that field will be tracked and appear in the History tab.
I am using SDL Tridion 2011 and need to take the permissions off from the user to localize a structure group so that he does not make any changes in the name of the structure group by localizing it. However, even after removing the rights and permissions and making the structure group ‘read only’, the user is still able to localize the structure group by right clicking on it and going to properties. Please help if there's any resolution for it.
Also, is there any way we can restrict the user from unpublising or updating a page?
Permissions on a structure group control what you can do to the things it contains. Remove the localize permission in the parent structure group instead.
To prevent unpublishing you can do any of the following:
Remove the Read permission.
Go to the Security tab in the properties of the relevant publication, and remove the right to Publish to Content Distributor
Go to the Security tab of the relevant Target Type, and remove the Use Target Type permission
To prevent them updating a page, remove the Write permission, although be aware that editing the page allows them to modify the page composition, and that controlling this doesn't prevent changes to the content if the person has permission to modify the relevant components.
If none of these is sufficient, then you will need to implement a custom solution with either the events system, or workflow.
Inspect the properties for your Structure Group and go to the Security tab. Check which users/groups have the localize right and then see if your user is a member of any of those groups. Groups can be members of other groups, so you may need to check recursively to find where this ability is being allowed from.
Also make sure that the user is not an Administrator.
To prevent a user from unpublishing a page then you need to make sure they do not have "Publish to Content Distributor" rights at the Publication level. If they need to be able to publish pages, but not unpublish, you will need to take care of that by writing an Event System.
To prevent them from updating a page, you need to consider the Write permissions on the containing Structure Group.
In evaluating the Invite and Support modules for Drupal recently, we realized the default tab navigation is not the most user friendly. In particular, each module has a page of tabs that show the various categories of invitations or support tickets (pending, cancelled, etc). For developers, it's easiest to pre-define all the tabs, but from a user standpoint, it makes more sense to only be offered the tabs that contain content.
I assume it's possible to run queries to check which tabs should be displayed for a particular user and change the menus using hook_menu_alter. However, is that the best way to do it or will that cause problems with Drupal's menu caching? Is there a better way?
The answer by jhedstrom is correct, but I'm not that convinced that dynamically showing/hiding local tasks results in better UX, that sounds kinda confusing to me.
Instead, my suggestion would be to use a title callback (which can be added with the same hook_menu_alter() and show the number of things inside that specific tab. That is what I for example use for Privatemsg to show the number of unread messages.
See privatemsg_title_callback() for an example and hook_menu for more information about title callbacks in general.
If you want to selectively remove tabs in a dynamic way (eg, one node gets a tab, while another does not), you won't be able to use hook_menu_alter() because that only has an effect when the menu cache is being built. However, you can do this by overriding the menu access callback. If access to a tab is denied, it won't be displayed.
For example, to override a node tab, you might do something like this:
function mymodule_menu_alter(&$items) {
$item['node/%node/foo']['access callback'] = 'mymodule_override_access';
}
function mymodule_override_access($node) {
// Perform queries, logic, etc to determine if content exists at node/nid/foo.
// Return false if there is no content, otherwise fall through to the original
// access callback function.
}