Jump to content

Valentijn Scholten

  • Content Count

  • Joined

  • Last visited

About Valentijn Scholten

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  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.
  • Create New...