When running a simple 'Get-PWDocumentsBySearch' command$Docs = Get-PWDocumentsBySearch -SearchName "$ProjectFolderPath\$pdfSearchName" -filename '%.pdf' -GetAttributes
I now get an error, which I never used to get beforeGet-PWDocumentsBySearch : Not logged in as a ProjectWise Administrator.
I am using the Open-PWConnection method because I don't want to use an administrator login -Admin parameter, the New-PWLogin method requires an administrator login and I don't want to use the GUI because this is on an automatic scheduled task.
ModuleType Version Name---------- ------- ----Binary 220.127.116.11 PWPS_DAB
Any assistance will be greatly appreciatedKind regards Gavin Chapman
We have updated ALL cmdlets within the PWPS_DAB module to require a ProjectWise Administrator login.
We have a 'Batch' user account that we use for certain automated tasks, these automated tasks manipulate data in one way or another, this account doesn't have admin rights and for certain reasons we don't want to give this account admin rights either. What was Bentley's reasoning for making the decision to update all the cmdlets to require an administrator login?
Kind regards Gavin
I hope this is a typo or requires some other context...
Similarly, for PWPS_DAB we use a "Service" account that is granted elevated rights to given Projects on a Project by Project basis, and it is definitely not a PWAdmin level account. Most of the functions in PWPS_DAB are user level functions anyway... why would you restrict those that can be done by regular users in the PWClient?
We use this on a regular basis to supplement an existing "PWSync" tool that Dave wrote for our company a few years ago, which is failing, and we are told our only recourse is to use the PWPS_DAB functions to replace that capability. With that tool, it HAD to run in the PWAdmin context, and there was a username/password tool to encrypt the Password value to be put into an excel spreadsheet.
In fact, our hope is to script certain bulk functions to work using the account/context of the user. An example is a series of actions with a 3rd Party Application, where processing or generation of a report is central to the function and deliverable, but is not captured by PW through Application Integration, and this resulting file would be scripted to automatically be pushed back into ProjectWise to allow the workflow to continue in ProjectWise. This would eliminate the problem of getting users to do the same task and speed the action, promoting workflows in ProjectWise.
If this is the case, we are frozen at the previous version of PWPS_DAB for the functions that have been written, and all user context work is now dead.
Really need some context and explanation here...
Since the inception of the PWPS_DAB PowerShell module, it has been our intention that this be used as an Administrative tool only. We are willing to expand the capabilities to the Restricted Administrators as well which will be available in future release of the module.
Ok, then we are stopped at 18.104.22.168 for the foreseeable future, or the "Restricted Administrators" comes alive and can be evaluated... do you have any timing on that effort? Days/Months/Years?
It is unfortunate that the both the PWPS and PWPS_DAB tools/modules are not separable by a "Admin Function" or "Anybody can" capability, really limits the use of the tools/modules and their uses.
Has there been any thought given to adding a "Encrypted Password" command/tool (similar to that Dave had provided for the "PWSync" tool that we had previously), where the logon to PWPS using "Open-PWConnection" could be passed the Encrypted Password, which would prevent the "Keys to the Kingdom" from being shared with a open Password?