I found out that when using Solution Workbench to create a solution file of BAQs, and then importing the solution into a new environment, the AuthorIDs are all set to the currently logged in user. On a small scale, this is probably OK, but I’m going to be manually updating AuthorIDs on ~500 BAQs after we go live on a new version of Kinetic. DMT is not an option, and a Datafix was not made available when I requested it.
Can anyone think of a reason why having the AuthorID modified to the current user on import would be beneficial? This is an honest question - I’m trying to figure out if there’s some angle here that I’m missing.
At any rate, I submitted an Epicor Idea for new functionality where the AuthorID is preserved. Log In - Epicor Identity
Beneficial? From an audit standpoint, it IS the person who created the BAQ in that environment afterall, so…
However, if you want to keep track of who made changes to customization items, may I suggest that this is yet another use case for having source control maintained outside the database?
Thanks for sharing the DevOps idea - I added a vote.
For AuthorIDs - it does more than just define who last edited the BAQ. If a BAQ is not shared, and the authorID changes, then the original author loses access to their own BAQ. If the BAQ is shared, then the original author loses access to edit their own BAQ, if they also don’t have the permission to change the BAQ author.
So there are unintended changes in behavior by changing the AuthorID. Ideally, all the good BAQs would be built into something like a dashboard or report, but we have several people that do things on the fly and I can’t lock down access any further right now.
At least from a DevOps perspective, one might argue that only the (automated) deployment user has capabilities to update BAQs (plus other customization objects) and the authors of those objects have their own dev/test/staging environments to work in. External source control would keep track of the changes and by whom, but when deploying to production, the deployment user (service) would extract the most recent version and deploy it. Ideally, Epicor would have the deployment details, and the commit ID of the object deployed.
Doing work in production makes our systems hard to replicate in a disaster but having that work stored externally makes deployments, new environments, and restoration so much cleaner. Off my soapbox…
True! With a real pipeline, we would know who authored the object (and EVERY revision to it), which revision was installed, when it was installed, who approved the deployment (if you wish), AND be able to do so for any environment.
We will never be able to do that if we store our source code in the environment.
From an audit standpoint, it IS the person who created the BAQ in that environment afterall, so…