Atelier ServerSide callback functionality enhancement needed

Question

Question

Trevor Strong · Sep 20, 2017

To be able to replace current Cache Studio user functionality in our source control system, I need to access the current project name that the atelier file belongs to when being checked out and in within the UserAction method of the source control class.
In addition to this, there also appears to be a problem in that when UserAction code is executed by the Atelier callbacks, the process is running as UnKnownUser instead of utilising the authentication values assigned in the Connection settings for the server.

Does anyone know if these properties are currently exposed?

I used ^||%Studio.Project when running Cache Studio hooks and $UserName from the UserAction callback.

Discussion (5)1

Log in or sign up to continue

Timothy Leavitt · Sep 20, 2017

I can't speak to a fix, but a few thoughts:

There is a critical difference between Studio and Atelier projects: Atelier projects are not even present on the server / in the database. This may prevent them from being used interchangeably with Studio projects for purposes of your source control extension and change control processes.
- Because of this difference, it would probably not be a good idea to populate ^||%Studio.Project with the name of the project in Atelier.
One option might be updating your source control extension (perhaps adding new menu items and UserAction/AfterUserAction handling for them) to support creating a %Studio.Project and associating/dissociating files with one, even from Atelier. This would support mixed use of Studio and Atelier and make migration simpler.
If you want to be able to detect in your source control extension code whether it is being called from Studio or Atelier, you can look at the StudioVersion property (defined in %Studio.Extension.Base). Particularly, this will contain the string "Atelier" if invoked from Atelier.

A nice enhancement for Atelier might be supporting a project definition that is shared between the client and server.

1 0

score 0 · Answer 1 · 2017-09-20T15:10:55-04:00

The current Atelier project is not exposed. What is your intended use case for it?

Regarding $Username - I suspect that the /api/atelier web application on your instance has only "Unauthenticated" selected under "Allowed Authentication Methods." If you change this to "Password" only and restart Atelier you should see $Username populated correctly.

score 0 · Answer 2 · 2017-09-20T15:26:17-04:00

Excellent, thanks. The security setting on the api/atelier/ application has performed exactly as you described.

Regarding the use case for the project name, we have a tight binding between project names and version control.

e.g. A Defect # is raised in our tracking system for code change. Currently, a cache studio project of the same name is utilised and all files in relation to the defect are associated to the cache studio project. This int turn is reflected in our cache source control system creating a binding between the file(s) involved in the correction and the project name they are linked to.

Assuming Atelier is now the source of truth for project names, we need to be able to bind this into our source control tracking process.

Maybe all the environment variables could be passed in to the process? e.g. resource_name, project_name, etc

score 0 · Answer 3 · 2018-02-15T13:46:22-05:00

Trevor, how does your source control mechanism deal with the way that Portal doesn't by default have any concept of "current project"?

Perhaps the project-related classmethods implemented in %CSP.Portal.SourceControl.Util were implemented for your use-case?

score 0 · Answer 4 · 2018-02-15T16:35:36-05:00

Hi John.

I don't allow SMP interaction due to this binding. We have a strict policy internally in the sense that noone can checkout and modify anything unless "bound" to a project. As such the VC project ensures that on checkout of an existing file, and/or on checkin of a new file, a project name is associated. This is then additionally linked to our R&D system for the official bugfix/requirement and associated comments.

Still waiting on a supported method of more visibility to look Atelier as a viable alternative for us.

All i need is a visible project name as i think they now cater for exposure of the full package.classname.

I could modify the version control software to do away with this concept and insist on manual selection of the log in R&D but thought it simpler to ask for the exposure of one variable from Atelier to make it all work.

Still waiting :)