Question
Vodafone
GB
Last activity: 4 Oct 2018 16:48 EDT
Limit Agile WorkBench to just feedback
Hello All
We are looking to enable our users to provide feedback on our application. I have previously tried to enable SMART feedback on out application https://community.pega.com/marketplace/components/smart-feedback but this seems to be limited to pega 7.2 where as we are currently running instances of 7.3 and 7.4.
We would like to enable the feedback CASE type and functionality within Agile WorkBench without giving the user any other abilities - Creating BUGS or STORIES.
In 7.4 have noticed that new WHEN rules have been added, pzIsFeedbackEditable,pzIsBugEditable and pzIsStoryEditable to the navigation pzCreateNewItemNav which leads me to think that there must be some way of achieving this. Unfortunatly these WHEN rules are all 'OR' statements. In order to give a user access to AgileWorkbench and enable to window on the right to popout we have to grant them pxAgileWorkbench privildge. This then satisfies all the WHEN rules and so shows all options - bugs, stories and feedback.
Ideally I am looking for a way for the user to be able to click a button or link, run the script "pega.ui.gapidentifier.toggle" and have the Agile Workbench appear on the right without having to give the user the pxAgileWorkbench priviledge. Or if this is needed, somehow have it limited to just feedback.
Has anyone got any ideas how I might achieve this?
***Updated by moderator: Lochan to update platform capability***
-
Like (0)
-
Share this page Facebook Twitter LinkedIn Email Copying... Copied!
Accepted Solution
Vodafone
GB
Sorry for the delay in replying, I have attached a few screenshots to explain what we have done.
Pega-Agile-Work.pyStartCase - we have added a when rule to the process tab
canCreateBugs - our when rule for access to raise bugs
Access Role User Cannot access - the users we do not want to use bugs or user stories have this added to their access role.
Although these steps do not hide the ability, they stop people from using the functionality. Ideally we would like to hide it however this works for us right now.
Pegasystems Inc.
IN
Say, if you want to remove the Stories and Bugs tabs for a specific access group, open/edit the privileges of the access role name as below:
Find/add the asset class, Pega-Agile-Work-UserStory and Pega-Agile-Work-Bug, add/make the privileges pxAgileWorkbenchItemReadOnly and pxAgileWorkbenchItemModify with level 0 for both of them.
No need to add pxAgileWorkbench privilege.
Observe that Stories and Bugs tabs have been hidden in Agile Workbench now. Hope this helps.
-
Durgarao Jeeri
Vodafone
GB
Hi Vitts thank you for this, issue I have though is that without the pxAgileWorkbench privilege, the script pega.ui.gapidentifier.toggle doesnt seem to run and so the user can't view the section/popout in order to add feedback. I thought I had solved this previously but the reason it appeared to work was because I had the pxAgileWorkbench priviledge and clicked to show the popout. I then removed the priviledge and added priveldges to just Pega-Agile-Work-Feedback. Worked fine until I logged out and logged in again.
-
Jean-Baptiste Dumuids
Coforge Limited
US
Thank you Vitts1 I was able to get this to work as you described but with some minor tweaks. I had to remove the pxAgileWorkbench privilege and instead added the class asset for Pega-Agile-Work-Feedback with pxAgileWorkbenchItemReadOnly and pxAgileWorkbenchItemModify set to level 5. There was no need to add the bug or userstory classes as the when condition to show Agile Workbench link only checks to see if they have the privilege and it is not null for visibility so there was no need to set up denial of access. My current set up now allows admins to have access to all 3 tabs but managers and users only have access to feedback.
Vodafone
GB
Hi MichaelS0877
This is really good to read that you go this working. I am curious though, without the pxAgileWorkbench privilege, how are the users able to see the Agile Workbench? Have you created a seperate button that calls the window into view?
Coforge Limited
US
Hello AndrewL9124,
I did not create a separate button. The button used by default worked just fine. If you check the when condition it is calling pyEnableAgileWorkbench, this has another when pzHasAgileWorkbenchPrivilege which calls 3 other when conditions that separately check to see if a user has access to change any of the tabs and if so it shows the button. I have taken screenshots of the when rules and attached below for reference.
Pegasystems Inc.
IN
Hoping it is working fine for you now.
If not, Then I have a set of questions
How are are trying to open Agile workbench , Is it default option available in Designer Studio/Express or any other portal or by run script manually anywhere else.
First thing to check would be to see how "Agile Workbench" link behaves in Designer studio , Let us know if that is also broken when you remove pxAgileWorkbench privilege.
pyEnableAgileWorkbench is the when rule that governs the visibility of "Agile Workbench" link.
Vodafone
GB
Hello All
Thank you very much for your help. In the end I still could not get this to work in exactly the way we wanted, however we did come up with a workaround that suited us.
Within each of the cases (BUG and USERSTORY) we added a WHEN condition to the Start Conditions on the Process tab of pyStartCase. We named these canCreateBugs and canCreateStories. The WHEN rules evaluated @HavePrivilege(tools,"pyCaseInstitutionalize","Pega-Agile-Work-Bug",null for BUGS and similar for Stories.
When then added the priviledge pyCaseInstitutionalize against the classes (Pega-Agile-Work-Bug and Pega-Agile-Work-UserStory) to the access roles we wanted to be able to use these.This means that although some users who we don't want to use these options can still see them in Agile Workbench, they can't use them. We can also then grant permissions to which ever access groups we wish.
Pegasystems Inc.
IN
I frankly do not see a need to do all these customizations, not sure whether you carried over such privilege needs even before 7.4 release, but good to see you made it work as per your requirements, which you may need to keep on maintain with Pega platform updates/upgrades. It will be great to see your implementation. Can you please share few screenshots on the roles that you configured for the access groups?
Please let us know if you still need anymore help and we can do a screen share by having an SR raised.
Accepted Solution
Vodafone
GB
Sorry for the delay in replying, I have attached a few screenshots to explain what we have done.
Pega-Agile-Work.pyStartCase - we have added a when rule to the process tab
canCreateBugs - our when rule for access to raise bugs
Access Role User Cannot access - the users we do not want to use bugs or user stories have this added to their access role.
Although these steps do not hide the ability, they stop people from using the functionality. Ideally we would like to hide it however this works for us right now.
-
Chris Kim