v0.6.3

Still based on SAS Extension for VS Code 1.21.0 (tag v1.21.0).

This release extends the SAS Clinical Acceleration support with electronic signatures: signature history (#130), signing files (#131) and linking an authenticator app for signing (#136). It also adds the audit history (#132) and searching the repository (#133). Signing files and linking an authenticator app haven't been tried against a server yet.

Features

• SAS Clinical Acceleration: Set Up Signing (Authenticator App)... links an authenticator app for signing files, as Enable Signatures in the settings of SAS Clinical Acceleration Repository does. It's in the Command Palette and the title bar menu of the Clinical Repository view, and Sign Files... offers it when the server refuses a signature. After a confirmation, it shows a new QR code to scan in a tab of its own, which runs no scripts and closes after 10 minutes. It isn't the Viewer, so Posit Assistant can't read the code, and the code isn't logged or saved. A new code replaces the signing key, so an app linked before stops working. The request (POST /repository/signatureKeys, which answers with a PNG) isn't in the API documentation; it was taken from the SAS Clinical Acceleration web app and wasn't tried against a server

• SAS Clinical Acceleration: Search Repository finds items in the Clinical Repository, as the Search page of SAS Clinical Acceleration Repository does: by name with * and ? (case is ignored), location (subfolders included), text in the files (AND and "phrases"), and optionally only files or folders, items you own, files you have checked out, signed files, and items modified in the last 7 or 30 days. It is in the title bar of the Clinical Repository view, as Search in This Folder... on folders, and in the Command Palette. Results, at most 500, appear in the new Clinical Repository Search view with the same context menu as repository items, plus Reveal in Clinical Repository; Edit Search..., Refresh Search and Clear Search are in its title bar. Content search uses repository/files with text, which the API documentation describes only for downloads; it was taken from the SAS Clinical Acceleration web app and checked against a server

• SAS Clinical Acceleration: the audit history of the repository, as in the Audit History page of SAS Clinical Acceleration Repository. Show Audit History in the context menu of the Clinical Repository view shows the audit records of an item, or of a folder and everything in it, as a report in the Viewer: date, who acted, action, item, location, mode, and what changed. Search Audit History... in the view's title bar menu and the Command Palette searches by name (with * and ?), location, actions, modes and period. Export Audit History... saves the last report as HTML or CSV. Reports list at most 1,000 records, newest first, and the changes of the first 100. Administrators see the actions of all users, other users only their own: the server returns them so, although the API documentation says the audit endpoints are for administrators only

• SAS Clinical Acceleration: Sign Files... signs repository files electronically, as in SAS Clinical Acceleration Repository: right-click files, or a folder to sign all its files, in the Clinical Repository view. It asks for the files to sign, a reason and a signatory role from the lists configured on the server, an optional comment, a confirmation, and last the current PIN of your authenticator app. Retry with a New PIN keeps the other choices. It needs the Sign Files privilege and an authenticator app linked in SAS Clinical Acceleration Repository; checked-out files are left out. The PIN is not logged or kept. The request (action=SIGN on /repository/items/batch with pin, role, reason, comment and paths) and the reasons and roles lists (/repository/signatureReasons, /repository/signatureRoles) are not in the API documentation; they were taken from the SAS Clinical Acceleration web app. Signing was not tried against a server, because a signature can't be removed

• SAS Clinical Acceleration: Show Signature History shows the electronic signatures of a repository file, or of one version of it, as a report in the Viewer: date, signer, role, reason and version, newest first, like the Signature History window of SAS Clinical Acceleration Repository. It is in the context menu of signed files in the Clinical Repository view and of signed versions in the Clinical Version History view. Export Signature History... saves the report as HTML or the signatures as CSV. The Clinical Repository view marks files whose latest version is signed with Signed, Clinical Version History marks signed versions, and Clinical Repository Properties has a Signatures row. Signing files is not part of this change. The signatures endpoint (/repository/items/{id}/signatures) appears in the API documentation only in an example, and the signing status of items (signingStatus) not at all; both were found by testing against a server, which had no signed files to list

v0.6.2

Still based on SAS Extension for VS Code 1.21.0 (tag v1.21.0).

Version 0.6.1 was prepared but never published, because a GitHub Actions outage stopped its release; its changes are part of this release.

This release extends the SAS Clinical Acceleration support: runs can be removed from the Clinical Jobs view and the Clinical Job Schedules view lists only your schedules (#120), Properties show your permissions and Check In explains refused files (#122), and clinical jobs can be run and populated and tested as repository runs (#123, #124). It fixes the check-in locations in the manifest report (#126) and the local SAS connection profile that could be lost on the first start in the SAS Analytics Pro image (#127).

Features

• SAS Clinical Acceleration: runs can be removed from the Clinical Jobs view. Remove from List hides the selected runs, and Clear Finished Runs in the title bar hides every finished run, also those on pages not loaded yet. Runs are only hidden in Positron, per user and server; the run history on the server stays. Show Hidden Runs, Restore to List and Restore All Hidden Runs bring them back
• SAS Clinical Acceleration: Show All Users' Schedules in the Clinical Job Schedules view lists the schedules of all users that the server returns, marked with their owner. Other users' schedules can only have their ID copied
• SAS Clinical Acceleration: Clinical Repository Properties shows Your permissions on the selected file or folder, such as READ and WRITE, and Your versioning privileges, as the server reports them. They explain why an action such as Check out to Workspace is missing
• SAS Clinical Acceleration: Check In says why it leaves files out instead of "None of the selected items can be checked in": a copy of a repository file that is not checked out to you can't replace a repository version (check the file out first, Without Content keeps your copy), and a file checked out by someone else can only be checked in by them. The SAS Clinical Repository output channel lists every file left out
• SAS Clinical Acceleration: Run and Populate Clinical Job... runs a job from the Clinical Workspace and, when the run succeeds, fills the job's Publish Setup with the files its programs read and the folders they write to, with relative or absolute paths, as described in the SAS Clinical Acceleration guide. A repository run gets only those inputs, so this prepares a job for running from the repository. Check-in locations are removed, as SAS Clinical Acceleration does. It is in the context menu of a .cjob file in the Clinical Workspace view, in the editor title bar menu, and in the job editor. The request shape (action=RUN_AND_POPULATE and the body field useRelativePaths) is not in the API documentation and was found by testing against a server
• SAS Clinical Acceleration: Test Clinical Job... runs a job from the Clinical Workspace as if it ran from the repository, as described in the SAS Clinical Acceleration guide: programs and inputs are read from the repository, and only the log, listing and manifest are written to the workspace, without check-in or audit record. It shows before check-in whether a job will run from the repository. File and folder parameters are picked in the repository. It is next to Run and Populate Clinical Job... in the context menu, the editor title bar menu and the job editor. The Clinical Jobs view marks test runs, Run and populate runs and scheduled runs, and Run Again repeats a run as the same kind

Bug Fixes

• Positron: the connection profile for a local SAS installation (such as the SAS Analytics Pro image) could be lost on the first start. Posit Workbench writes settings.json at session start, and a profile write of the extension that overlapped it failed with "The content of the file is newer", leaving settings.json with an empty SAS.connectionProfiles. The extension no longer writes an empty SAS.connectionProfiles when it reads the setting or when no profile is active. It writes the local profile and the active profile in one write and retries a failed write with backoff. It marks the profile as added only once it can read it back, so a failed add is tried again at the next start. If every retry fails, a warning offers Retry
• SAS Clinical Acceleration: the manifest report showed "Check-in locations: None" for repository runs that had check-in locations. The report reads the manifest from the clinical jobs service, whose copy can lack the locations that the run's .cmnf file records. When it does, the report now takes the check-in settings from the .cmnf file, at the version the run wrote, and the SAS Clinical Repository output channel notes it
• SAS Clinical Acceleration: the Clinical Job Schedules view listed other users' schedules and offered to run, change and delete them. The service returns other users' schedules too, although its documentation says it returns the current user's. The view now lists the schedules that run as you, like the Clinical Jobs view lists your runs

v0.6.0

Still based on SAS Extension for VS Code 1.21.0 (tag v1.21.0).

This release adds clinical jobs to the SAS Clinical Acceleration support: running jobs and following their runs (#113), manifest reports with links to the files of a run (#114, #116), Run as Clinical Job (#115), a job editor (#117), and schedules (#118). It also lets Posit Assistant write SAS reports as Quarto documents and exports the SAS connection for saspy (#111, #112).

Features

• New command SAS: Export saspy Configuration. It writes the active SAS connection profile as a saspy sascfg_personal.py next to the open .qmd file (or in the workspace folder), for sasquatch and saspy. SAS Viya profiles read their token from the SAS_VIYA_TOKEN environment variable, so no secret is written. Posit Assistant runs the same command when it sets up a SAS report
• New command SAS: Save Viya Token for saspy. It saves the access token of the extension's SAS Viya sign-in (including a Posit Workbench token) to ~/.positron-sas/viya-token.json, readable only by the user, so a Quarto render with sasquatch can connect without a separate sign-in. The exported saspy configuration now looks up the token each time saspy connects: the SAS_VIYA_TOKEN environment variable, the Workbench OAuth integration (needs posit-sdk and the integration ID), then that file
• Posit Assistant: a new sas-quarto-report skill makes /report and other report requests about SAS work produce a Quarto document with {sas} chunks run through the sasquatch R package. Before, the Assistant asked whether to use R with haven or Python with pandas, because only Positron Assistant saw the sasquatch note. The skill also explains that the rendered report opens its own SAS session, so it must load data from permanent libraries or files and not from WORK tables of the console session
• Posit Assistant: the sas-quarto-report skill now requires a blank line after the last *| option line in every {sas} chunk (without it, knitr reads only the first option), lints the chunks before it renders, renders the report itself when the setup is complete, and says "done" only after a render succeeded. Otherwise it says "Written, not rendered" and why
• SAS Clinical Acceleration: run clinical jobs. Right-click a .cjob file in the Clinical Workspace or Clinical Repository view and select Run Clinical Job. The extension asks for the job's parameters, follows the run in a notification whose Cancel cancels it, and offers the run's log and results when it ends. Verified against a server for workspace jobs with text parameters. Repository jobs, date parameters and file or folder parameters use request shapes from the API documentation and are not yet verified against a server
• SAS Clinical Acceleration: new Clinical Jobs view with your clinical job runs and their live state. Expand a run to see its manifest, the audit record of the run: the programs with their result and run time, the parameter values, the input and output files with version and checksum, the logs and results, and outputs that were not checked in. A versioned repository file opens at the version the run used. Right-click a run to open its log, results or job, run it again with the same values, cancel it, or copy its ID. The view appears when the server runs SAS Clinical Job Management
• SAS Clinical Acceleration: Show Manifest Report shows the manifest of a clinical job run as a page in the Viewer, where Posit Assistant can read it: the job, how the run ended, who ran it and when, the parameter values, the programs with result and run time, and each input and output file with version, size, modification time and MD5 checksum, plus the check-in settings and failures of repository jobs. It is available on runs in the Clinical Jobs view, on .cmnf files, and in the notification at the end of a run. Export Manifest... saves the report as HTML or the manifest as JSON
• SAS Clinical Acceleration: Run as Clinical Job runs a .sas program from the Clinical Workspace as a clinical job, so the run gets a manifest. It is in the context menu of the program in the Clinical Workspace view and in the Run menu and context menu of the editor. The first run creates a job named after the program (adsl.cjob for adsl.sas) next to it, and later runs reuse it. Unsaved changes are saved first. If a job of that name runs other programs, you can create a new job (adsl-2.cjob) or replace it
• SAS Clinical Acceleration: in the manifest report, the paths of the job, programs, inputs, outputs, logs and results are links that open the file in Positron. A versioned repository file opens at the version the run used. The links work while the report is open in Positron; an exported report has plain paths
• SAS Clinical Acceleration: manifest (.cmnf) files, and clinical job (.cjob) files opened as text, are JSON documents, with JSON highlighting, folding and formatting
• SAS Clinical Acceleration: clinical jobs (.cjob) open in a new clinical job editor, a form for the description, the programs and their order and versions, the parameters with type and default, the output locations, and the inputs and check-in of repository runs. It checks the job as you edit it, saves like any file, and has Run and Open as JSON buttons. New Clinical Job... on a Clinical Workspace folder creates a job and opens it. Repository jobs open read-only. Reopen Editor With... shows a job as JSON
• SAS Clinical Acceleration: schedule clinical jobs. New Schedule... on a .cjob file (in the Clinical Workspace and Clinical Repository views, the job editor, and the new Clinical Job Schedules view) asks when the job runs: once, on several dates, every few minutes, hourly, daily, weekly, monthly or yearly (by day number or by weekday, such as the first Monday), with a first day, an end, the time zone and the parameter values. The Clinical Job Schedules view lists your schedules with their timing, job, parameter values and next runs, and offers Run Now, Edit Schedule..., Disable and Enable Schedule, and Delete Schedule.... The service supports this although its public API documentation only describes reading schedules

Bug Fixes

• Positron: HTML results no longer fail to appear when the Viewer is used right after a window opens. The Viewer serves HTML files through Positron's built-in proxy extension, and until that extension had started, the report stayed blank without an error. The extension now starts the proxy first, and if the Viewer still does not show the report, it shows the HTML directly
• SAS: Export saspy Configuration no longer shows a modal "already exists, replace it?" dialog, which blocked Posit Assistant for as long as nobody answered it. When sascfg_personal.py exists with other content, the command keeps the old file as sascfg_personal.py.old-<timestamp>, writes the new one, and shows a notification with the backup path. The command's result also returns backupPath

v0.5.3

Still based on SAS Extension for VS Code 1.21.0 (tag v1.21.0).

This release gives the SAS Clinical Acceleration views their own activity bar icon (#108) and removes the sign-in confirmation dialog for SAS Viya in Posit Workbench (#107).

Features

• SAS Clinical Acceleration: the four Clinical Acceleration views now have their own Clinical Acceleration icon in the activity bar instead of sharing the SAS sidebar with SAS Content and SAS Server. The icon appears only when the server has Clinical Acceleration. Clinical Repository Properties and Clinical Version History start collapsed

Bug Fixes

• SAS Viya: signing in no longer shows an "extension wants to sign in" confirmation dialog when a session is already available, such as the Posit Workbench token that the extension picks up automatically. The dialog appeared on every fresh Posit Workbench session until the extension was on the account's allow-list. The extension now uses an available session directly and starts the interactive sign-in only when there is none

v0.5.2

Still based on SAS Extension for VS Code 1.21.0 (tag v1.21.0).

This release adds a Clinical Workspace to the SAS Clinical Acceleration support, with check in, versioning and compare (#103), and it keeps an idle SAS Viya console from losing its SAS session (#105).

Features

• SAS Clinical Acceleration: new Clinical Workspace view with your own workspace on the server. Files open for editing and are saved to the workspace when you save the editor. You can create, rename, delete, upload (optionally expanding a zip), and download files and folders, copy paths, and compare files with repository files and versions. Verified against the SAS Clinical Acceleration extension's requests and unit tests, not yet against a server with write access
• SAS Clinical Acceleration: Check In from the workspace asks only what applies to the selected files (whether to version new and unversioned files, Major or Minor for versioned files, and a comment). Undo Check out is available in the workspace too
• SAS Clinical Acceleration: Copy to Workspace copies the latest version of a file or folder, or the structure of a folder, from the repository to the workspace. Copy to Workspace in the Clinical Version History view copies one version. .sas files in the workspace run as usual, and .sas7bdat and .xpt files open in the Data Explorer
• Posit Assistant: the new sas-clinical-acceleration skill describes the Clinical Acceleration views and the check-out and check-in workflow
• Docs: new page "SAS Clinical Acceleration"; README and the Features page no longer say that you need another tool to check files in
• Clinical Repository: new Clinical Repository Properties and Clinical Version History views show the details and the versions of the selected item. A version opens read-only and can be downloaded
• Clinical Repository: Delete (moves items to the recycle bin of the Clinical Repository), Enable Versioning... and Disable Versioning... for files, and Select for Compare, Compare with Selected and Compare Selected for repository files and file versions. Delete, versioning and compare are verified against the SAS Clinical Acceleration extension's requests and unit tests, not yet against a server with write access

Bug Fixes

• SAS Viya: an idle console no longer loses its SAS session. The Viya server ends a compute session that gets no requests for its inactivity timeout, and the next submit then failed with a 404. The extension now contacts an idle session every 60 seconds (setting SAS.session.keepAliveSeconds, 0 turns it off) and stops after 8 hours without a submit. If the server has dropped the session anyway, the next submit starts a new one and says so in the log, because the WORK library and macro variables of the old session are gone. Verified against a real Viya server: both GET .../state and GET .../sessions/{id} reset the inactivity timer, a console left idle for more than 10 minutes still responded, and after the compute session was terminated the next submit started a new session. The server's default inactivity timeout is not known (#105)
• Clinical Repository: Upload and Upload and Expand now send the file as multipart/form-data, as the Clinical Repository API specifies, and no longer version the upload by default. The version prompt is empty unless you enter a version (such as 1.0, MAJOR or MINOR), because versioning needs a privilege that normal users often lack (#73). Verified against the API specification and unit tests, not yet against a server with write access
• Clinical Repository: after the sign-in token expires, the first request no longer fails with a 401. The request that triggers the refresh is now replayed with the new token instead of the old one (#101)

v0.5.1

Still based on SAS Extension for VS Code 1.21.0 (tag v1.21.0).

This release is mostly documentation: the site is now "SAS Extension for Positron Documentation" and covers running SAS in Posit Workbench (#99). The only change to the extension is an updated dependency.

Bug Fixes

• Updated the katex dependency from 0.17 to 0.18.10 (#97)
• Docs: new section "SAS with Posit Workbench" (SAS within Positron: local SAS, SAS over SSH, and SAS Viya with sign-in through Workbench; SAS in R and Python code with saspy and sasquatch) and a "Positron SAS Extension Features" page, with screenshots. The documentation of the SAS Extension for Visual Studio Code is kept and linked from the new pages
• Docs: the installation page describes installing the extension from the VSIX file of a GitHub release, in Positron and in Posit Workbench, and keeps the instructions for the SAS Extension for Visual Studio Code
• Docs: the site is renamed "SAS Extension for Positron Documentation", its GitHub and edit links point to posit-dev/positron-sas-extension, and the footer has the Posit copyright line for the Positron specific parts

v0.5.0

Still based on SAS Extension for VS Code 1.21.0 (tag v1.21.0).

This release lets a SAS Viya profile sign in with the Posit Workbench OAuth token, so you sign in to SAS Viya once (#93). The local profile is now also added for SAS 9.4 installs (#87), and each SAS console starts the profile you picked, with its own SAS session (#94).

Features

• Positron: the local stdio profile is now also added for SAS 9.4 installs. Besides the SAS Analytics Pro path, the extension looks in common SAS 9.4 Foundation locations (such as /usr/local/SASHome/SASFoundation/9.4/bin/sas_u8) and for sas on PATH. For SAS 9.4 it uses the UTF-8 launcher bin/sas_u8, because the extension reads SAS output as UTF-8. The new SAS.localSasPaths machine setting lists extra launcher paths, checked first (#87)
• stdio profiles now run their autoExec lines once, right after SAS starts (#92)
• Posit Assistant: sas_export_saspy_config exports a SAS Viya profile as a saspy HTTP access method configuration (url, context, and an authtoken read from the SAS_VIYA_TOKEN environment variable) instead of an IOM configuration. The exported configuration never contains secrets, and profile names that are not Python identifiers are converted to valid configuration names (#91)
• SAS Viya: in Posit Workbench, a SAS Viya profile signs in with the SAS Viya token from a Posit Workbench OAuth integration configured by your administrator, so you do not sign in to SAS Viya a second time. New profile settings authentication ("auto", the default, "workbench", or "sasLogon") and workbenchIntegration. Without a matching integration, the extension signs in with SAS Logon as before (#93)

Bug Fixes

• Positron: starting the runtime "SAS (profile)" now connects with that profile, not with the active profile (#88)
• Positron: each SAS console has its own SAS session. Before, consoles of the same connection type shared one SAS process or compute session, and shutting one down closed it for the others (#89)
• Positron: interrupting an SSH or stdio session no longer marks the console idle while SAS keeps running the code. These connections cannot cancel a submission, so the console stays busy and a message offers to restart the session, which stops SAS. Restarting or reconnecting a stdio session now starts a new SAS process instead of reusing the one that is shutting down (#90)
• In VS Code (outside Positron), .sas7bdat and .xpt files open in the default editor instead of a viewer that needs a Positron SAS session (#92)
• Removed the "SAS: View Data" command, which was declared but did nothing; the repository and bugs links now point to posit-dev/positron-sas-extension (#92)
• Docs: the stdio README and profile docs describe the actual SAS startup options and example file, additional.md uses the saspath key, and the capabilities matrix and connection type flowchart include SAS 9.4 (local - stdio) (#92)

v0.4.0

Still based on SAS Extension for VS Code 1.21.0 (tag v1.21.0).

This release adds local SAS: Positron can run a SAS installed on the same machine, such as SAS Analytics Pro in a Posit Workbench session, with no SAS servers and no SSH (#82).

Features

• New stdio connection type for SAS installed on the same machine: the extension starts SAS directly, without SSH or SAS servers. Based on sassoftware/vscode-sas-extension#1771 by Andreas Menrath
• Positron: when SAS is installed at /opt/sas/viya/home/SASFoundation/sas, as in SAS Analytics Pro images, a local stdio profile is added once, so SAS shows up in the console without setup. In Posit Workbench, SAS is licensed by the session
• Positron: stdio sessions get the Connections pane library browser and the Data Explorer, which run SAS code in the session

Bug Fixes

• The connection type "SAS 9.4 (local)" is Windows-only (COM) and is now offered only on Windows. On other systems it could only fail with write EPIPE; choose "SAS 9.4 (local - stdio)" for a local SAS instead
• A stdio profile whose saspath is missing or not executable now fails with an error that names the path

v0.3.1

Still based on SAS Extension for VS Code 1.21.0 (tag v1.21.0).

Features

• Posit Assistant can now see SAS results #74:
  • Graphs from console runs are drawn as PNG and also sent to the Plots pane, where the Assistant can look at them. A run with graphs ends with the Plots pane in front, as in R and Python; the full HTML report is in the Viewer
  • A plain-text copy of the output (titles and tables) goes to the Assistant with each run's result. The console only shows a short note
  • The HTML report now opens in the Viewer as a file, so the Assistant can read it and take screenshots of it, including for code you run yourself. Reading the Viewer needs Positron 2026.10 or later
  • A sas-results skill tells the Assistant where SAS output goes (log in the Console, reports in the Viewer, graphs in the Plots pane) and how to read it (Positron 2026.10 or later)

Bug Fixes

• Positron: Run, Run Selection and Run Region in a .sas file now run the code in the SAS console, as Positron does for R and Python. Results open in the Viewer pane instead of a Result tab that split the editor area, and the log shows in the console #77
• The SAS console now shows the full SAS log of the code you run: the source, NOTEs (including %put NOTE: ... output), warnings and errors. Lines from the code Positron wraps around yours are left out. The same lines are added to the "SAS Log" output channel, without switching the panel away from the Console

What's Changed

• Fix the docs site's base URL for posit-dev.github.io by @michaelmayer2 in #75
• Deploy the docs from the pushed commit, not the version tag by @michaelmayer2 in #76
• Show the full SAS log for console runs by @michaelmayer2 in #78
• Run SAS editor code in the Positron console by @michaelmayer2 in #79
• Let Posit Assistant see SAS plots, tables and the Viewer by @michaelmayer2 in #80
• Release 0.3.1 by @michaelmayer2 in #81

Full Changelog: v0.3.0...v0.3.1

v0.3.0

Still based on SAS Extension for VS Code 1.21.0 (tag v1.21.0).

Features

• SAS Clinical Acceleration Repository view: it is detected automatically when the active profile is a SAS Viya profile whose server runs the Clinical Repository service, and it uses the existing SAS Viya sign-in. You can browse, open (read-only), create folders, rename, upload or upload and expand, download, copy paths, and check out / undo check out. Actions that change an item (check out, rename, new folder, upload) are offered only where you have write permission, so read-only files still show Copy Path and Download. Ported from SAS's Clinical Acceleration extension for VS Code #60
• Traceability of SAS console code, including code run by Positron Assistant #58:
  • New setting SAS.audit.logFile: when set, every console submission (user, host, Positron and Posit Workbench session, profile, code) and its outcome are appended to that file as JSON Lines
  • Each submission carries a /* positron: user=… session=… exec=… */ comment, so it can be traced in the SAS log
  • The macro variables &POSIT_USER, &POSIT_SESSION and &POSIT_WORKBENCH_SESSION are set at session start
  • SAS Viya compute sessions are named Positron SAS (<user>) and carry the user and session ids as attributes. Each console job is named positron-console, and its description holds the user, session and execution ids

Bug Fixes

• Errors and warnings from the SAS log now show as squiggles in the editor and in the Problems pane when you run code from a .sas file into the Positron console (Run Selection or the statement at the cursor). Code typed into the console or generated by Positron Assistant shows them in the console only #68
• Data Explorer: SAS transport files (.xpt, XPORT v5 and v8/9, and PROC CPORT files) now open in the Data Explorer instead of as text. A file that holds several datasets asks which ones to open #64
• Opening a .sas7bdat file now reports a failed LIBNAME (for example, a path the SAS server can't see) instead of an empty Data Explorer
• .sas7bdat and .xpt files opened from the Clinical Repository or SAS Content views now load in the Data Explorer: they are copied into the session's WORK directory first, which also works when SAS runs in lockdown

---

What's Changed

• Add Positron API integration tests and CI workflow by @jonvanausdeln in #36
• Collate Dependabot updates into one monthly PR and apply pending updates by @michaelmayer2 in #63
• Open SAS transport (.xpt) files in the Data Explorer by @michaelmayer2 in #65
• Make SAS console submissions traceable to user and session by @michaelmayer2 in #66
• Add the SAS Clinical Acceleration Repository view by @michaelmayer2 in #67
• Open datasets from the Clinical Repository and other non-local views by @michaelmayer2 in #69
• Offer Clinical Repository write actions only where the user may write by @michaelmayer2 in #70
• Map SAS log problems from console runs back to the editor by @michaelmayer2 in #71
• Release 0.3.0 by @michaelmayer2 in #72

New Contributors

• @jonvanausdeln made their first contribution in #36
• Special thanks to @samiulhq for the valuable feedback that informed most of the features in this release

Full Changelog: v0.2.1...v0.3.0