- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-19-2014 09:02 AM
Following the instructions in the Wiki our admin team is unable to create new Releases or Sprints in either the SDLC or StartNow applications (they reference the same objects from two places)
We can create and manage new Stories, Enhancements, and Defects, however, and the entirety of both applications were working during our Quick Start in Q1.
Suggestions on where to look further?
Thanks in advance.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-27-2016 12:55 PM
Hilariously enough, I'm running into this exact issue over two years later - only this time, I'm having the issue with ***a brand new, out of the box Fuji Installation**...on a ServiceNow Developer Instance that I stood up an hour ago! *facepalm* My own difficulty from two years ago is the first Google result for this.
The correct answer is that the default conditions for the NEW button UI Action eliminate all possible users when selecting RELEASES from the left-hand Application Menu.
The condition out of the box is current.canCreate() && !RP.getListControl().isOmitNewButton() && RP.isRelatedList() && !RP.isManyToMany() && RP.getViewManager().getViewName() != ''
Removing && RP.isRelatedList() from the default condition allows the UI Action to properly place the New button at the top of the list when reaching the form via the SDLC (scrum) -> Releases menu item.
We have also ensured that we have users with the rm_release_admin role, and that the rm_release_admin role has Create rights in the ACL for rm_release_scrum but admin overrides that ACL, so it was definitely the isRelatedList() that was blocking everyone (including Admin) from accessing the New UI Action on the form. 😃

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-19-2014 11:52 AM
Actually, what you're showing on screen matches what I have. The "List banner button" option that is selected is what places it at the top of the open release list. The form button is if you wanted that action to show up on the form view of the release, so not needed for "New" actions.
Are there any versions listed in the related lists for that action? If not then it probably wasn't changed. Below is the script from Dublin patch 1 unchanged for comparison.
var uri = action.getGlideURI();
var path = uri.getFileFromPath() + '';
path = path.substring(0, path.length - 5) + '.do';
uri.set('sys_id', '-1');
path = checkWizard(uri, path);
if (path)
action.setRedirectURL(uri.toString(path));
action.setNoPop(true);
function checkWizard(uri, path) {
var already = uri.get('WIZARD:action');
if (already == 'follow')
return null;
var wizID = new GlideappWizardIntercept(path).get();
if (!wizID)
return path;
uri.set('sysparm_parent', wizID);
uri.deleteParmameter('sysparm_referring_url');
uri.deleteMatchingParameter('sysparm_list_');
uri.deleteMatchingParameter('sysparm_record_');
uri.deleteParmameter('sys_is_list');
uri.deleteParmameter('sys_is_related_list');
uri.deleteParmameter('sys_submitted');
uri.deleteParmameter('sysparm_checked_items');
uri.deleteParmameter('sysparm_ref_list_query');
uri.deleteParmameter('sysparm_current_row');
uri.set('sysparm_referring_url', uri.toString());
uri.deleteMatchingParameter('fancy.');
uri.deleteMatchingParameter('sys_rownum');
uri.deleteMatchingParameter('sysparm_encoded');
uri.deleteMatchingParameter('sysparm_query_encoded');
uri.deleteParmameter('sysparm_refer');
return 'wizard_view.do';
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-19-2014 12:00 PM
One Version, dated 1/4/14, source System Upgrades, State= Current.
...and the script is the same.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-19-2014 12:04 PM
It's looking like you probably need to go the HI ticket route on this one so they can dig into your system. We've covered the most likely scenarios. Sorry I couldn't get you to a solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-19-2014 12:11 PM
I thought that might be the case.
Thanks, Jared!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-27-2016 12:55 PM
Hilariously enough, I'm running into this exact issue over two years later - only this time, I'm having the issue with ***a brand new, out of the box Fuji Installation**...on a ServiceNow Developer Instance that I stood up an hour ago! *facepalm* My own difficulty from two years ago is the first Google result for this.
The correct answer is that the default conditions for the NEW button UI Action eliminate all possible users when selecting RELEASES from the left-hand Application Menu.
The condition out of the box is current.canCreate() && !RP.getListControl().isOmitNewButton() && RP.isRelatedList() && !RP.isManyToMany() && RP.getViewManager().getViewName() != ''
Removing && RP.isRelatedList() from the default condition allows the UI Action to properly place the New button at the top of the list when reaching the form via the SDLC (scrum) -> Releases menu item.
We have also ensured that we have users with the rm_release_admin role, and that the rm_release_admin role has Create rights in the ACL for rm_release_scrum but admin overrides that ACL, so it was definitely the isRelatedList() that was blocking everyone (including Admin) from accessing the New UI Action on the form. 😃