Jump to content

Valentijn Scholten

Members
  • Content Count

    20
  • Joined

  • Last visited

Everything posted by Valentijn Scholten

  1. Hi, In previous versions of Passwordstate the following features were present when requesting access to a password list: 1) The list of password list administrators was shown 2) The requester could choose which administrator to notify: 1 administrator from the, or all in the list My users are reporting they are missing feature 1. The use case is that we have lots of lists and lots of administrators, each team managers their own lists. When a user requests access, and it's urgent, they would like to know who the admins are so they can "chase" their request. Feature 2 would also be nice to have to prevent 2,3,4, administrators from getting a notification e-mail. But this is more nice to have. Please let us know your thoughts, Valentijn
  2. A feature requeset to have a recycle bin for password lists is (more or less) here: https://www.clickstudios.com.au/community/index.php?/topic/2311-single-password-password-list-recovery/&tab=comments#comment-5900
  3. +1, especially because deleting a password lists currently also deletes all associated audit logs.
  4. Hi, Recently I noticed that when removing a password list all associated audit log records are also deleted. My opinion is: - An Audit log should be append only. I understand that at some point it might get truncated. - The message currently being displayed when deleting a password list is not making clear the audit log is being deleted as well. I understand that "all related records" is very broad, but in my experience users don't expect audit logs to be deleted. - I will also raise a recycle bin feature request (if not already present). A recycle bin could help if can only be 'cleared' by passwordstate admins. Valentijn
  5. Hi, I'd like to encourage users to use the default password generator as this has a high minimum length. Until now password lists were created with password generator policy "My Personal Generator". I have changed the template to use the "Default password generator policy", so new password lists will be OK. Is there an easy way (or SQL query) to change all existing password lists? Valentijn
  6. I also think the query above does not take the number of members of a group into account? I might take a look at adjusting the query as we are possibly looking at making sure all lists have at least 2 admins.
  7. I agree the query works fine, but it requires SQL access. I wouldn't want to allow too many servicedesk people access to the database (and bypassing audit logs). So would be nice to have the report in place. The primary usecase I would use this report is when/before deleting a user. So ideally the report would be "Password lists for which a user is the only admin".
  8. Hi, Currently the main page for a password list displays the recent activity for that list (last 30 days, max 500 records). This is very useful, but sometimes you wonder about things that happened to the list longer ago. i.e. Who created it? Who changed permissions? When? Who added which password? It would be very convenient to have a link to the audit log and have this password list selected automatically. It can be done manually, but you have to remember the exact name/location of the list, especially if you have multiple lists looking a like. Valentijn
  9. Hi, Sometimes it happens that people are leaving our company. When their account is deleted (or disabled) it can result in passwordlists having no admin anymore. As far as I can tell there's no easy way to generate a report of these lists, so that would be a welcome addition to passwordstate. Any work arounds maybe? Valentijn
  10. Ah, so there's another setting somewhere controlling this. Thanks for letting me know, again couldn't find it using google, pdf, help search.
  11. Thanks, but the question is not where to find the documentation but how users can find it. Currently the link in the help menu is hidden, even when the user has permission to toggle the API key visibility. It seems that the visiblity of the menu item is linked to whether the user can generate api keys, where it might seems more logical to link it to the permission of being able to toggle the api key visibility? Also, it only hides the link from the menu. The link still works, so it is not really a security control. There may also be users that may want to consult the api documentation even if they do not _yet_ have permission to use it / see API keys. So my suggestions: - Make the link to api documentation always visible - Make the search function in the help section return a pointer to the api documentation in some way.
  12. Thanks. I was hoping to get is a builtin field/step when changing access. If it's a seperate step people need to take manually afterwards, they will quite often not use it.
  13. No. In hindsight it's always easy, but I wasn't expecting a the api settings to spread across multiple pages. I did try a search for "generate api key" though: Next question I got from the affected user is where they can see the WEB api documentation. Is this governed by the the same setting as generating an api key?
  14. Looks like I found it. I couldn't find it in the manual or with google, so maybe there's some improved documentation possible.
  15. Hi, When granting new permissions to a user on a passwordlist, you can specify a "reason for access". This is very good and helpful as an audit trail of why a user has been given access. I would like the same feature to be present when changing an existing permission. For example when as a list admin you change the permission of somebody from 'View' to 'Modify' or even to 'Admin'. Thanks, Valentijn
  16. Hi, Some users needs to use an API key with their password lists. We have set the "Enable the 'Toggle Visibility of Web API IDs' menu for Password List Administrators only (if set to No, users with Modify rights will also have access to this menu):" to No But the toggle visiblity remains greyed out for users with modify permissions. I have now given the users admin permission on those list. This allows them to toggle the visibility of the API key. However, the API key is set to 'None'. They can access the API key tab in the properties of the list, but the 'Generate API key' button is greyed out. What permissions must a user have to be able to generate an/the API key? It looks like all API keys have to be generated by a Passwordstate system administrator? I'm using build 8165 Valentijn
  17. Just adding my vote here as currently user credentials are going over the line in plaintext which ideally want to avoid.
×
×
  • Create New...