Mercurial > hg > orthanc
changeset 6398:55db426a8667
merge
| author | Alain Mazy <am@orthanc.team> |
|---|---|
| date | Wed, 12 Nov 2025 18:02:18 +0100 |
| parents | 252867eea2db (current diff) cf8715d1aaf0 (diff) |
| children | 1facef20a778 ded8a2be0d46 18a70fb61b91 |
| files | |
| diffstat | 5 files changed, 12 insertions(+), 13 deletions(-) [+] |
line wrap: on
line diff
--- a/OrthancFramework/Sources/SystemToolbox.cpp Wed Nov 12 18:00:57 2025 +0100 +++ b/OrthancFramework/Sources/SystemToolbox.cpp Wed Nov 12 18:02:18 2025 +0100 @@ -1029,27 +1029,25 @@ boost::filesystem::path SystemToolbox::InterpretRelativePath(const boost::filesystem::path& baseDirectory, - const std::string& relativePath) + const boost::filesystem::path& relativePath) { - boost::filesystem::path relative = SystemToolbox::PathFromUtf8(relativePath); - /** The following lines should be equivalent to this one: - return (base / relative); + return (baseDirectory / relativePath); However, for some unknown reason, some versions of Boost do not make the proper path resolution when "baseDirectory" is an absolute path. So, a hack is used below. **/ - if (relative.is_absolute()) + if (relativePath.is_absolute()) { - return relative; + return relativePath; } else { - return baseDirectory / relative; + return baseDirectory / relativePath; } }
--- a/OrthancFramework/Sources/SystemToolbox.h Wed Nov 12 18:00:57 2025 +0100 +++ b/OrthancFramework/Sources/SystemToolbox.h Wed Nov 12 18:02:18 2025 +0100 @@ -136,7 +136,7 @@ static void GetEnvironmentVariables(std::map<std::string, std::string>& env); static boost::filesystem::path InterpretRelativePath(const boost::filesystem::path& baseDirectory, - const std::string& relativePath); + const boost::filesystem::path& relativePath); static void ReadFileRange(std::string& content, const boost::filesystem::path& path,
--- a/OrthancServer/OrthancExplorer/explorer.js Wed Nov 12 18:00:57 2025 +0100 +++ b/OrthancServer/OrthancExplorer/explorer.js Wed Nov 12 18:02:18 2025 +0100 @@ -173,8 +173,8 @@ var authorizationTokens = GetAuthorizationTokensFromUrl(); -/* Copy the authoziation toekn from the url search parameters into HTTP headers in every request to the Rest API. -Thanks to this behaviour, you may specify a ?token=xxx in your url and this will be passed +/* Copy the authoziation token from the url search parameters into HTTP headers in every request to the REST API. +Thanks to this behaviour, you may specify a ?token=xxx in your url and this will be passed as the "token" header in every request to the API allowing you to use the authorization plugin */ $.ajaxSetup( {
--- a/OrthancServer/Plugins/Samples/Basic/Plugin.c Wed Nov 12 18:00:57 2025 +0100 +++ b/OrthancServer/Plugins/Samples/Basic/Plugin.c Wed Nov 12 18:02:18 2025 +0100 @@ -239,7 +239,7 @@ else { const char* studyId = request->groups[0]; - int32_t statusHasChanged = 0; + uint8_t statusHasChanged = 0; if (strcmp(request->groups[1], "stabilize") == 0) {
--- a/TODO Wed Nov 12 18:00:57 2025 +0100 +++ b/TODO Wed Nov 12 18:02:18 2025 +0100 @@ -64,7 +64,8 @@ https://discourse.orthanc-server.org/t/instances-id-content-api-results-are-different-in-docker-swarm-replicas-of-orthanc/4582 * Allow saving PrivateTags in ExtraMainDicomTags. Note: they can actually be stored but they then appear as "Unknown Tag & Data" in the responses. - If we try to add the PrivateCreator in the ExtraMainDicomTags, then, the DICOMWeb plugin fails to initialize because the private tags are not known. + If we try to add the PrivateCreator in the ExtraMainDicomTags, then, the DICOMweb plugin fails + to initialize because the private tags are not known. * Support hashed passwords in RegisteredUsers. E.g: "RegisteredUsers": { "admin": { @@ -266,7 +267,7 @@ * (3) Check out rapidjson: https://github.com/miloyip/nativejson-benchmark * Long-shot & not sure it is even feasible at all: try to reduce memory usage by implementing streaming - when receiving DICOM instances from the Rest API or from DICOM and store files directly to disk as they + when receiving DICOM instances from the REST API or from DICOM and store files directly to disk as they are received. Note that this would likely require rewriting large parts of Orthanc. Note sure that would be compatible with Transcoding. Use case: receiving 10 1GB instances in parallel can consume up to 20 GB
