Sarge

Hi All, We're getting the following error: Regardless of what folder ID we specify. Any thoughts?

I'll agree with this aspect, the request access to passwords/password lists is not very intuitive and a lot of our users don't know the option exists until its pointed out. The rest of your post I may not be fully understanding, but sounds to me like the structure of your password lists/folders may need reviewing to achieve what you want.

Hi All, Our policies are we don’t delete accounts – we just disable them. When we migrated from Forms Auth to Domain Auth, we’ve ended up with duplicate accounts (at least, first name and last name). It would be nice to have a feature where the application will hide accounts if they’ve been disabled; on all screens where searching for a user / group is required. Or as an alternative, display the user’s login username in brackets.

No worries. I'm probably showing my ignorance but I'd have thought it'd be a kin to showing the difference of a database value for the system setting prior to change and then after the change; while prepending the users unique identifier.

It would be nice to have an audit log for all additions or modifications made via the application administration section; including what setting was changed to what. Example: "User XX changed XX setting from XX to XX". "User XX added Active Directory security group XX from the domain XX" "User XX granted Active Directory security group XX modify rights to the template XX" In a multi-administrator environment being able to know these changes and revert them if required would be hugely beneficial; especially when many modifications are made but may not be captured in the work notes the user maintains.

+1, with the caveat that it's applied per password list. We have a team that'd like this feature, while our other teams wouldn't, so applying it to the password lists (directly or via a template) would give the ability to be selective.

Passwordstate with LDAP integration is something I requested some time ago, under tracking ID PS-1992. Assuming theres enough demand for it, it would allow integration with IPA for authentication and host discovery. IPA is a bundle of tools, ldap being one of the tools it bundles. We also use IPA for our Linux servers authentication. Assuming wkleinhenz would like this as a feature request, I'd have to +1 it.

Sweet. RFC raised.

Thanks guys, thats awesome. Won't get a chance to upgrade until next week as today I'm still performance an RFC and finalising the migration to the new webserver and SQL cluster; I still have to convert to AD auth.

Thats a lot of pages! Lets go with the custom.css for now, plus maybe a seperate one for login / log out page?

Found it.... We stopped with the custom CSS when we went to v8 because it become to difficult to keep verifying changes. So it would be nice to be able to get these changes back, but on a per-page basis. I understand its a lot of leg work and you've already got a lot in the pipeline for this year. /* Start Changes */ /* Changes made to adjust Logo TR to be White, while keeping existing base color specified in Admin Control Panel */ /* This ensures the logo fits the color scheme */ /* keeps the specified base color in Admin Control panel on the login and logout screens. This effectively overwrites what is set in Admin Control Panel. Ensure you update the color when you change base color in admin control panel.*/ td.BaseColor { background-color:#22428C !important; } /* sets the background color of the login and log out screens white, overwritting what we set in the admin control panel. */ body.BaseColor { background-color:white !important; } /* Hides the "Forms Based Authentication" text on the index page and the Company - Password Manager text on the loggedoutpopup.aspx page. */ div.title2 { font-size:0px !important; } /* The below changes target individual element IDs to adjust color. By default these where all white - which blended in with the Body.BaseColor change above */ #BuildDiv { color: #C0C0C0 !important; } #ActiveUsersTD { color: black !important; } #A2 { color: black !important; } #NewBuildLabel { color: #545454 !important; } #MaintenanceModeDiv { color: red !important; } #A5 { color: red !important; } #QueuedEmailsDiv a:link { color: red !important; } #QueuedEmailsDiv a:visited { color: red !important; } #PendingAccessRequestsDiv { color: black !important; } #A1 { color: black !important; } /* END Changes */

Yep it sure would be , however it would be my preference. There was other things we changed in the CSS on the login screens and log out screens. I'll try and find the old CSS we used as it was somewhat substantial changes, more than just BaseColor.

In the context of my post it was for the Passwordstate login screens. At one stage we were also hiding some elements on the login screens via the CSS as well as changing the headerTable to force a different background colour (thus overriding the base colour it inherits). Minimal at this stage because it becomes to difficult to verify lots of changes after each upgrade, but at this stage. Body Background, btn-info Background & Border Colour, btn-info:hover Background & Border Colour. body { padding: 3em 15px; background: #ffffff; /*background: rgb(93,101,144); Old browsers background: -moz-linear-gradient(-45deg, rgba(93,101,144,1) 0%, rgba(54,169,225,1) 100%); FF3.6-15 background: -webkit-linear-gradient(-45deg, rgba(93,101,144,1) 0%,rgba(54,169,225,1) 100%); Chrome10-25,Safari5.1-6 background: linear-gradient(135deg, rgba(93,101,144,1) 0%,rgba(54,169,225,1) 100%); W3C, IE10+, FF16+, Chrome26+, Opera12+, Safari7+ filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#5d6590', endColorstr='#36a9e1',GradientType=1 ); IE6-9 fallback on horizontal gradient */ /* display: table;*/ font-family: "Raleway", sans-serif; } .btn-info { color: #fff; background-color: #003255; border-color: #003255; } .btn-info.focus, .btn-info:focus, .btn-info:hover { background-color: #00C8C8; border-color: #00C8C8; }

Hi All, I raised this by email but thought I'd put it here to get any additional +1s. We’ve made some customisations to the CSS for the SelfDestruct portal and will be doing so to the PasswordReset Portal. Upgrades currently overwrite these customisations and require the customisations to be put back in place with each upgrade, this isn't as simple as a copy and paste, as we need to ensure nothing in the original CSS has changed that will break the customisations. It would be nice to have access to the CSS and embedded styles, and for the customisations to be remembered across upgrades. This would allow far greater flexibility in customisations and branding; and remove the need to reapply and test customisations with each upgrade. I'd suggest moving each CSS into the database, and then have a new system setting section dedicated to branding/customisations. Currently the base colour sets the page background for the login/logout screens; we'd rather have this set to a colour other than the base colour, but the only way to achieve this is to modify the CSS. This, and the ability to customise the button colours on the portals is an example of greater flexibility for the customers branding requirements that this feature request could achieve. Part of this request would be confirmation in the change log of any changes to styles that have occurred as part of the upgrade.

Hi Chris, If you upload the script and any required CSVs I can take a look during my spare time.