Encontrar

InterSystems Official
· 9 jul, 2024
Open Exchange

Git-source-control launches release 2.4.0 with a new basic mode

#Embedded Git #Git #GitHub #InterSystems Package Manager (IPM) #Código abierto #Control del origen #InterSystems Official

The Application Services team is pleased to announce the release of git-source-control version 2.4.0, introducing several new features to the open-source project.

For those unfamiliar, git-source-control is an embedded (or "server-side") source control tool for InterSystems products, installed through the InterSystems Package Manager.

 

 

Here are the key additions to the 2.4.0 release:

  1. Basic Mode

Basic mode presents an overall great simplification to the git workflow, suitable for users with less knowledge of git as a source control tool. The basic mode has been explicitly developed for the feature branch and trunk-based models of development.

In basic mode, the typical flow of staging, committing, pulling and then pushing has been enveloped in a 'Sync' operation. Users need only choose the 'Sync' operation from the menu, and their local changes will automatically be synchronized with the corresponding branch in the remote repository (on GitHub, GitLab, etc.).

To enable basic mode, simply navigate to the 'Settings' page of the git-source-control tool, either through the embedded menu or the web UI, and select the 'Use Basic Mode' option in the user settings at the bottom of the page.

        2. Revamped Workspace UI

The workspace section of the git-source-control Web UI provides an area for users to take actions on changes to their repository.

Previously, it was divided into four segments, a diff view, a working copy view, a commit message view and a staging area.



 

 

With the new workspace view, the working copy and staging area have been collapsed into a single list of files with checkboxes, and it's clearer that the commit message is a text field. The diff view has been enhanced, allowing uncommitted files from other IRIS users to be viewed in the diff view, which previously was not supported. We believe these changes make the user interface much more intuitive.

 

          3. Default Merge Branch

In basic mode, a new setting for the 'default merge branch' allows users to specify a branch whose remote copy will be merged into the current branch before pushing to the remote repository.

This setting was implemented to provide additional built-in support for the trunk-based source control approach. Merging with this option will also automatically resolve a common class of merge conflict that occurs when multiple developers are working on the same IRIS Interoperability production.

 

Notable Bug Fixes:

            1. Git commands changing local repository files now synchronize with IRIS

Previously, the checkout, merge, rebase, stash and discard operations did not have their changes to the local file tree reflected by IRIS. Now, upon any of these commands being run, IRIS will update to provide file versions that match the local repository, including deleting files that don't exist in the current branch, or adding files that only exist in the current branch. This also compiles the changed files, which is especially important for changes to interoperability productions to reflect in the Production Configuration page.

             2. Deleted files are now shown in the Workspace UI

Previously, files deleted in the repository would not show up as one of the changes in the workspace. This meant that deletions would go unstaged and uncommitted, leaving the deleted files lingering in the repository. In the new UI, not only do all types of file changes (including deletions) show in the workspace, but the files are also listed with the corresponding git action, such as "modified", "added", "deleted" or "renamed."

 

              3. Users with %Developer are now able to perform all actions though the package without the need for added roles

In some cases, users were unable to perform many of the package's operations with being granted additional SQL privileges. This is no longer the case, simplifying security configuration.

 

 

For a full list of features and bug fixes introduced by the 2.4.0 release, please see the changelog.md file in the git-source-control repository on GitHub.

We are always looking for feedback and improvements for the git-source-control tool! Please feel free to create a GitHub issue in the repository if you encounter a bug or think an important feature is missing.

1 Comentario
Comentarios (1)2
Inicie sesión o regístrese para continuar
Anuncio
· 9 jul, 2024

[Video] Using Artificial Intelligence / Machine Learning for Pain Assessment in a Clinical Environment

#Artificial Intelligence (AI) #Global Summit 2023 #Machine Learning (ML) #Video #Summit #InterSystems IRIS for Health

Hi Community,

Watch this video to learn about the PainChek artificial intelligence technology, which assesses patient pain at the hospital bedside, leverages InterSystems IRIS interoperability to connect to third-party electronic medical record systems:

⏯ Using Artificial Intelligence / Machine Learning for Pain Assessment in a Clinical Environment @ Global Summit 2023

Presenters:
🗣 Philip Daffas, CEO and Managing Director, PainChek
🗣 James Matthias, Head of Product - Adult, Enterprise

Subscribe to our YouTube channel InterSystems Developers to get notified about new videos!

Comentarios (0)1
Inicie sesión o regístrese para continuar
Pregunta
· 9 jul, 2024

Has anyone worked with <MAXSTRING> in Fhir R4 Binary deserialization (From Athena)?

#DTL #FHIR #JSON #InterSystems IRIS for Health

I'm running into an intermittent issue with some of our Custom Operations/Processes as a result of some large FHIR R4 Binaries. Essentially we get a response from an AthenaHealth FHIR endpoint that appears to be too large to be processed using the IRIS Built In Functions for FHIR:

I've replicated it on the command line here using a file (binary.json) that has the response from the FHIR Endpoint. Not sharing full contents due to PHI concerns.

HSCUSTOM>S file=##class(%Stream.FileCharacter).%New()

HSCUSTOM>Do file.LinkToFile("/data/binary.json")

HSCUSTOM>w file.Size
4033045

HSCUSTOM>Set FhirBinary = ##class(HS.FHIR.DTL.vR4.Model.Resource.Binary).%New()

HSCUSTOM 2d1>Do FhirBinary.FromJSON(file,"vR4")

<MAXSTRING>%GetNext+12^%Iterator.Object.1

 

Looking into the Class Code:
 

/// Pure binary content defined by a format other than FHIR.
Class HS.FHIR.DTL.vR4.Model.Resource.Binary Extends HS.FHIR.DTL.vR4.Model.Base.Resource [ Not ProcedureBlock ]
{

/// code
/// <p>
/// MimeType of the binary content.
/// <p>
/// mimetypes|4.0.1 is the REQUIRED FHIR4 ValueSet for codes; 
/// you may NOT extend mimetypes|4.0.1 and you may NOT use codes from other ValueSets.
Property contentType As %String(MAXLEN = 1000000, XMLNAME = "contentType", XMLPROJECTION = "ATTRIBUTE") [ Required ];

/// Reference
/// <p>
/// Identifies another resource to use as proxy when enforcing access control.
/// <p>
/// Any FHIR4 Resource may be indicated by this Reference
Property securityContext As HS.FHIR.DTL.vR4.Model.Base.Reference(XMLNAME = "securityContext", XMLPROJECTION = "ELEMENT");

/// base64Binary
/// <p>
/// The actual content.
Property data As %Binary(XMLNAME = "data", XMLPROJECTION = "ATTRIBUTE");

It appears the data is stored as a %Binary (which is basically a %String) and hits the <MAXSTRING> error.

Sample data:
 

{

"contentType": "image/png",
"data": "<LONG Base64 Encoded Content>",
"id": "XXXXXXXXXXX",

"meta": {

"security": [

{

"code": "NOPAT",

"display": "no disclosure to patient, family or caregivers without attending provider's authorization",

"system": "http://terminology.hl7.org/CodeSystem/v3-ActCode"

}

]

},

"resourceType": "Binary"
}

 

I'm essentially trying to deserialize so I can get at the content-type, security, and id properties easily to determine if we do anything with the Base64 itself. It seems odd that productized code from IRIS wouldn't handle this, although I can't say I'm super confident the source data is complying to any standards outside of shape.

We could refactor our existing code to handle SOME of this using DynamicObjects:

HSCUSTOM>s dynObj={}.%FromJSON(file)

HSCUSTOM>w dynObj.contentType
image/png

HSCUSTOM>w $EXTRACT(dynObj.data,1,100) W $EXTRACT(dynObj.data,1,100)
^
<MAXSTRING>

That said, if I still need to access the binary content itself, I'm not sure the best way to handle that. If anyone has run into anything similar, I'd appreciate some feedback.

Thank you!
-Vic

1 Comentario
Comentarios (1)2
Inicie sesión o regístrese para continuar
Comentarios (0)1
Inicie sesión o regístrese para continuar
Pregunta
· 9 jul, 2024

Generating module.xml on IRIS Server

#InterSystems Package Manager (IPM) #API REST #InterSystems IRIS #VSCode

I'm working with isc.rest and am going through the tutorial right now. My project directory exists on my IRIS server. When I try to create a module.xml file in the root package, I get a #16006 error. I see that there is a "generate" command for zpm that should create a module.xml for me on my local filesystem. How can I create this module.xml in the same folder that holds my code living on the IRIS server?

1 Comentario
Comentarios (1)2
Inicie sesión o regístrese para continuar