please can you indicate why these would not be needed. Authentication through to 3rd party tool would be done on user by user basis typically.
They are not always needed. In our case, we were only given a set of account name and password in the company's in-house issue tracking tool for all of our users so we embeded it inside the code of our plug-in to the issue tracking tool. There is no need for the users to go through authentication, and the mandatory username and password text boxes from Silk Java APIs actually make our users very confused.
So, we need a capability to hide username and password text boxes.
Please can you validate if the seperate permission for ‘Remove Execution plan’ resolves your issue.
currently you can set permissions to restict who can remove execution plans introduced in 15.5.
Further review to consider if can make execution plans obselete prior to delete.
We did restrict the users from deleting execution plans or testing cycles directly. However, we don't restrict the users from deleting or moving tests organized to a testing cycle due to need of allowing the users to organize the tests. What happened and we observed is that, when a user mistakenly removed all tests made to an execution plan, the execution plan was also gone, and this phenomenon puzzled us for a while until we realized what's going on, but we had no way to retrieve the execution plan. So this request is asking, instead of removing an execution plan from the database, it would be better to add bit columns for related tables and set them to off when the execution plan is removed. By doing this, at least we still have a way to recover it.
review of delete for tests to first make test obsolete then final delete
We have a item on our backlog which relates to deleted tests first moving to a ‘Obselete’ folder on first delete. This allows them to be reviewed prior to final delete. This is in line with how we handle requirement deletion.
We will add your feedback to out item on backlog.
Some of our users just accidentally deleted tests and test containers. Yes, we need this recovery feature.Peng Lin supported this idea ·
on backlog item to add additional customer statuses for issues in Silk Central. No time scale planned yet
We also need this feature to be implemented soon. We also use JIRA. For our testing purpose, we have to define custom issue statuses in JIRA. However, when we integrate JIRA with Silk, we realized we have to map 20 more JIRA statuses to 5 Silk issue statuses, and all statistic information in "Issues" unit turned out to be useless....
Yes, we need this feature!