Hello, here is this month's iRODS news and developments!

Click here to read this email on the web.

Obligatory Calls To Action:

• Book a FREE iRODS Audit

• Book a FREE iRODS Security Audit

iRODSNews

The iRODS User Group Meeting for this year has been announced - Barcelona!

Are you going?

I'd love to, but its right in the middle of my eldest child's GCSE exams...

Mastodon Toots

• The new iRODS HTTP API Python Wrapper Library v0.1.0 is released!

  https://github.com/irods/irods_client_http_python/

  Via PyPI:
  pip install irods-http

  #python
  #irods
  #http
  #pypi

  Card: GitHub - irods/irods_client_http_python
  Description: Contribute to irods/irods_client_http_python development by creating an account on GitHub.

• iRODS Development Update: February 2026

  https://irods.org/2026/02/irods-development-update-february-2026/

  logical locking

  policy composition

  crc64/nvme checksums

  storage tiering

  cyberduck updates

  #irods
  #python
  #cyberduck

  Card: iRODS

• Join us for Community Office Hours!

  https://fosstodon.org/@irods/116025435038198439

  Join us for Community Office Hours!

  Wed, Feb 11, 4-5pm ET

  https://renci.zoom.us/meeting/register/PI9KLyFQRgOUs5YRqB7MUA

• iRODS Community Office Hours

  Wed, Feb 11, 4-5pm ET

  Ask questions.

  Discuss the news of the day.

  Not recorded.

  A safe place to learn.

• National Center for High-Performance Computing (NCHC) joins the iRODS Consortium

  https://irods.org/2026/01/nchc-joins-the-irods-consortium/

  The National Center for High-Performance Computing (NCHC), a major national
  research infrastructure organization supporting high-performance computing
  (HPC), AI, large-scale data services, and scientific research across Taiwan,
  has become the newest member of the iRODS Consortium.

  #irods
  #taiwan
  #safedata

  Card: iRODS

• iRODS Development Update: January 2026

  https://irods.org/2026/01/irods-development-update-january-2026/

  Card: iRODS

Issue Highlights:

I'd like to call out a couple of issues further down the newsletter;

• Oracle Database Support Deprecation - Oracle is being removed as a database option. I only know of one other consortium member that used Oracle, and I've not encountered others outside it, so if you use Oracle, then take note! And if you want help migrating, let me know - my database colleagues and I moved a 500 million row database a few years back and I can share how we prepared, what checks we did and so on, as well as our approach.

• HTTP API - the bane of my life over the years has been timeouts when uploading large files, especially if you're Doing The Right Thing(tm) and calculating checksums. On a multi GB or even TB file it can add quite a delay to the upload process, and things like load balancers and /proc/sys/net/ipv4/tcp_keepalive_time can cause disconnects and disruption to the control plane, which in turn cause files to not be registered in the catalog properly or seem to fail to upload. Read below for a similar issue in the HTTP API and how the user is working around it. As its a live issue I expect a fix will be around the corner!

• If you write your own systemd configuration (as most of us do, all our systems are different after all), then check out the cautionary tale in the "RemoveIPC=no" issue. My colleagues, the fine RENCI folks and I have been looking for the reason for this for years!

GitHub Activity

Main Repository (irods/irods)

Open Issues – irods/irods

• acDeleteCollByAdmin no longer called

  State: open
  Labels: consortium-member, configuration
  Description: ## Bug Report

### iRODS Version, OS and Version
iRODS 4.3.1, Ubuntu 18.04

### What did you try to do?

I'm testing iRODS rule logic on an iRODS 4.3.1 server. The rule logic works on iRODS 4.1.10. When testing the behavior of the PEP acDeleteCollByAdmin, it no longer appears to be called when iadmin rmcoll is executed.

### Expected behavior

When a collection is administratively deleted, I except the PEP acDeleteCollByAdmin to be triggered.

• Tickets: Server allows write byte count to exceed write byte limit

  State: open
  Labels: bug
  Description: ## Bug Report

  When a ticket is used and write byte count matches write byte limit, the server will allow the operation to succeed. The reason for this is partially due to the following code block. Notice line 1452.

  Tracing how the server handles iput -f -t <ticket> shows a call sequence containing the following functions (ordered).

  1. rsDataObjPut

  2. rsDataObjOpen

  3. rs_data_object_finalize

  4. checkObjIdByTicket (contains the code block above)

  5. rsDataObjWrite

  6. rs_data_object_finalize

  7. checkObjIdByTicket (contains the code block above)

  The important part is that checkObjIdByTicket is invoked twice. The way tickets are currently implemented makes reasoning about the code difficult.

  Changing line 1452 in checkObjIdByTicket to use >= instead of > creates other problems - i.e. checkObjIdByTicket detects a violation on the second invocation, leading to a stale replica.

  The real solution is probably to refactor how the server handles tickets. Or, deprecate the existing API and introduce a new one.

• Ticket string silently truncated in catalog

  State: open
  Labels: bug
  Description: ## Bug Report

While working on #2720, I wrote a test which attempts to create a ticket named issue_2720_uses_count_using_iput.

iticket create write the_data_object issue_2720_uses_count_using_iput

The creation of the ticket appears to be successful as no errors are reported by the server or icommands. Unexpectedly, the test fails when attempting to modify properties of the ticket because the ticket's name is truncated in the catalog. Notice the ticket_string column below.

ICAT=> select * from r_ticket_main ;
 ticket_id |         ticket_string         | ticket_type | user_id | object_id | object_type | uses_limit | uses_count | write_file_limit | write_file_count | write_byte_limit | write_byte_count | ticket_expiry_ts | restrictions |  create_ts  |  modify_ts
-----------+-------------------------------+-------------+---------+-----------+-------------+------------+------------+------------------+------------------+------------------+------------------+------------------+--------------+-------------+-------------
     37257 | issue_2720_uses_count_using_i | write       |   37251 |     37256 | data        |          0 |          0 |               10 |                0 |                0 |                0 |                  |              | 01770675075 | 01770675075
(1 row)

The schema for r_ticket_main shows that the table is capable of holding a string of 100 characters.

ICAT=> \d r_ticket_main
                        Table "public.r_ticket_main"
      Column      |          Type          | Collation | Nullable | Default
------------------+------------------------+-----------+----------+---------
<snip>
 ticket_string    | character varying(100) |           |          |
<snip>

The TicketAdmin API and supporting functions need to be checked to make sure ticket strings use consistent sizes.

• Allow privilege escalation in policy

  State: open
  Labels: enhancement
  Description: ## Enhancement

When policy is triggered, it is normally executed as the user who invoked the related API. This is fine/good in most cases. However, there are cases where certain operations need rodsadmin level privileges. See https://github.com/irods/irods_rule_engine_plugin_logical_quotas/issues/132 for such a case.

It would be helpful if admins could write policy which temporarily escalate privileges for rodsadmin level operations. As of this writing, the only known solution to this problem is to write C++ plugins. If this feature were provided, admins would then be able to implement functionality only supported by C++.

### Requirements

• Use of privilege escalation is LIMITED to rodsadmin users

• Use of privilege escalation is server-side only - i.e. CANNOT be used via irule

• Use of privilege escalation in server-side policy DOES NOT block non-rodsadmin users

• delay() and remote() MUST NOT bypass stated requirements

### Syntax Ideas

Here are some ideas showing how the feature could look.

pep_api_data_obj_put_pre(*args ...)
{
    do_work();
    do_more_work();

    # Escalate privileges. De-escalate privileges on the
    # closing curly braces.
    @rodsadmin {
        rodsadmin_operation_1();
        rodsadmin_operation_2();
    }

    do_even_more_work();
}

pep_api_data_obj_put_pre(*args ...)
{
    do_work();
    do_more_work();

    # Escalate privileges. De-escalate privileges on the
    # closing curly braces.
    exec_as_rodsadmin("<options>") {
        rodsadmin_operation_1();
        rodsadmin_operation_2();
    }

    do_even_more_work();
}

pep_api_data_obj_put_pre(*args ...)
{
    do_work();
    do_more_work();

    # Escalate privileges.
    rodsadmin_session_begin();
        rodsadmin_operation_1();
        rodsadmin_operation_2();
    # De-escalate privileges.
    rodsadmin_session_end();

    do_even_more_work();
}

### Possible Solutions

• Modify the NREP and PREP

• Ship modified implementations of the NREP and PREP alongside the stable ones

• Make implementing C++ plugins significantly easier (must be a 10x improvement)

• Make a new language (must be a 10x improvement)

### Things to Consider

• Error handling during escalation

• Error handling while in an escalated state

• Testability - verification of correctness

• Server redirects while in an escalated state

### Miscellaneous Notes

• PEPs defined in core.re always take precedence over user submitted code (irule)

  • User submitted code is appended

  • The first definition wins

• Tracking/Inspecting stackframes could lead to interesting capabilities

• See https://github.com/irods/irods_rule_engine_plugin_logical_quotas/issues/132#issuecomment-3802102344

• Release activities for 4.3.5

  State: open
  Labels: documentation
  Description:
  version - [ ] Release notes

• Remove Oracle database plugin

  State: open
  Labels: deprecation / removal
  Description: Depends on #8829.

• What should we do with plugins/experimental?

  State: open
  Labels: question
  Description:
  experimental APIs which are currently unsupported. They were first
  introduced as part of #5007. We should consider doing one of the following:
  Move these into a separate repository - Officially support them and move
  them out of the experimental space - Delete them

• collapse multiple authentication error codes

  State: open
  Labels: enhancement
  Description: ### New Feature / Functionality

The server should not distinguish to the client why an authentication request failed. There should be a single error code returned, regardless of internal logic or codepaths.

• Use ccache in GitHub Actions when compiling iRODS code

  State: open
  Labels: testing, build / tools
  Description:
  https://github.com/irods/irods_reusable_github_workflows/pull/27

• GenQuery incorrectly joins R_DATA_MAIN when querying COLL_ACCESS_NAME, causing empty collections to be omitted

  State: open
  Labels: bug, consortium-member
  Description: ## Bug Report

GenQuery incorrectly joins R_DATA_MAIN when querying COLL_ACCESS_NAME, causing empty collections to be omitted

### iRODS Version, OS and Version

• iquest version: v4.3.4

• iRODS server version: v4.2.8

### What did you try to do?

I executed an iquest command to list sub-collections and their associated ACLs (permissions) under a specific parent path:

iquest "SELECT COLL_NAME, COLL_ACCESS_NAME, USER_NAME, USER_ZONE, USER_TYPE WHERE COLL_PARENT_NAME = '/iplant/home/iychoi'"

### Expected behavior

The GenQuery should generate SQL that joins R_COLL_MAIN with R_OBJT_ACCESS to retrieve collection permissions. It should not involve R_DATA_MAIN, as the query is specifically targeting collection attributes (COLL_NAME, COLL_ACCESS_NAME).

The expected result should include all sub-collections, including those that do not contain any data objects.

### Observed Behavior (including steps to reproduce, if applicable)

The generated SQL incorrectly includes a join on R_DATA_MAIN and an extra alias for R_OBJT_ACCESS. This forces an intersection where only collections containing at least one data object are returned.

#### Resulting SQL (Incorrect)

-- GenQuery included R_DATA_MAIN and r_data_access unnecessarily
select distinct R_COLL_MAIN.coll_name ,r_coll_tokn_accs.token_name ,R_USER_MAIN.user_name ,R_USER_MAIN.zone_name ,R_USER_MAIN.user_type_name
from R_COLL_MAIN , R_TOKN_MAIN r_coll_tokn_accs , R_USER_MAIN , R_OBJT_ACCESS r_data_access , R_DATA_MAIN , R_OBJT_ACCESS r_coll_access
where R_COLL_MAIN.parent_coll_name = '/iplant/home/iychoi'
  AND R_USER_MAIN.user_id = r_data_access.user_id
  AND R_DATA_MAIN.data_id = r_data_access.object_id
  AND R_COLL_MAIN.coll_id = R_DATA_MAIN.coll_id  -- This join filters out empty collections
  AND r_coll_access.access_type_id = r_coll_tokn_accs.token_id
  AND R_COLL_MAIN.coll_id = r_coll_access.object_id
order by R_COLL_MAIN.coll_name;

As a result, only 12 rows were returned. Collections like /iplant/home/iychoi/analyses and /iplant/home/iychoi/ticket_test were missing because they presumably contain no data objects.

#### Manual Verification (Correct SQL)

When I manually run the query without the data-tier joins, I get the correct 19 rows:

select distinct R_COLL_MAIN.coll_name ,r_coll_tokn_accs.token_name ,R_USER_MAIN.user_name ,R_USER_MAIN.zone_name ,R_USER_MAIN.user_type_name
from R_COLL_MAIN , R_TOKN_MAIN r_coll_tokn_accs , R_USER_MAIN , R_OBJT_ACCESS r_coll_access
where R_COLL_MAIN.parent_coll_name = '/iplant/home/iychoi'
  AND R_USER_MAIN.user_id = r_coll_access.user_id
  AND r_coll_access.access_type_id = r_coll_tokn_accs.token_id
  AND R_COLL_MAIN.coll_id = r_coll_access.object_id
order by R_COLL_MAIN.coll_name;

• Consider adding RemoveIPC=no to service unit file template

  State: open
  Labels: question, setup / deployment, configuration
  Description:
  experiencing this issue on 4.2.7, it was discovered that the iRODS service
  account was not a system user and we observed that systemd was repeatedly
  deleting the iRODS shared memory files. It's possible that the system got
  this way because the iRODS service account user was created before the setup
  script created the user as a system user (the setup script invokes useradd -r, where -r indicates that it is a system user). > > We resolved the
  issue in this case by modifying /etc/systemd/logind.conf to explicitly set
  RemoveIPC=no. This should go in the unit file, not in a system-wide
  configuration. However, given that this will disable cleanup of "System V
  semaphores, as well as System V and POSIX shared memory segments and message
  queues", and given that this issue was with a 4.2.7 deployment, I am
  skeptical as to whether it is a good idea to add this to our unit file
  template.

• irods::query::empty returns size_t instead of bool

  State: open
  Labels: bug, build / tools
  Description:
  🤦

Closed Issues – irods/irods

• Closed on 2026-02-13:

  Deprecate iadmin subcommands

• Closed on 2026-02-10:

  std::memset called on RsComm can result in undefined behavior

• Closed on 2026-02-10:

  Do not brace-initialize nlohmann-json objects with other json objects.

• Closed on 2026-02-05:

  Use irods::authentication::scheme_name instead of string literals

• Closed on 2026-02-03:

  core_tests_list.json missing several test suites in scripts/irods/test

• Closed on 2026-01-28:

  clang-tidy: Possibly uninitialized values used in update_replica_access_table

• Closed on 2026-02-04:

  Document or change the effects of disabling and re-enabling group quotas

• Closed on 2025-08-18:

  Switch Debian 13 docker image bases from debian:trixie to debian:13

• Closed on 2026-01-27:

  iRODS 4.3.3 Crash (SIGABRT): Double free or corruption in clearBBuf when handling storage I/O error

• Closed on 2026-02-02:

  Move icommands back into main repo

• Closed on 2026-01-28:

  Update library_features.h to include new features

• Closed on 2026-01-20:

  replication resource does not work during a rebalance operation

• Closed on 2026-02-13:

  msiSetKeyValuePairsToObj fails with 4.3.4

• Closed on 2026-02-05:

  Serialize ticketAdminInp for pep_api_ticket_admin_*

• Closed on 2025-05-09:

  Logger throws JSON exception when passed invalid UTF-8 sequences

• Closed on 2026-02-03:

  Remove build hook python script from main repo

• Closed on 2026-02-04:

  irmtrash doesnt remove directories

• Closed on 2026-02-03:

  rc_data_object_modify_info does not check the RcComm for null pointers

• Closed on 2026-02-03:

  irsync -l does not show data objects that need to be synchronized due to content changes

• Closed on 2026-02-11:

  iCommands: Deprecate --rlock and --wlock options

• Closed on 2026-02-11:

  update_deprecated_columns.py updates needed

• Closed on 2026-01-26:

  Data object mtime of zero-length files not updating after ingest and istream

• Closed on 2026-02-05:

  apt-key add has been deprecated

• Closed on 2026-01-27:

  ireg and iunreg bypass logical locking

• Closed on 2026-01-29:

  initial irodsctl call during upgrade to 4.2.8 fails due to ICAT password

• Closed on 2026-01-24:

  prepareNonServerSharedMemory error

• Closed on 2026-02-09:

  Document how to setup, create and manage quotas

• Closed on 2026-01-21:

  Quota functionality working inconsistently

• Closed on 2026-01-29:

  server should cleanly exit if not enough logging space on startup

• Closed on 2026-02-10:

  Tickets will increment both uses and write-file on failed access

Python iRODS Client (irods/python-irodsclient)

Open Issues – irods/python-irodsclient

• allow access of MetadataManager options as attributes

  State: open
  Labels: enhancement
  Description:
  obj.metadata.reload is True (as that's the default) but
  obj.metadata(reload=False).reload reflects the modified value of False

• Mistake in Username in env file leads to NetworkError

  State: open
  Labels: bug, consortium-member
  Description:
  which uses the pam module to authenticate users. When I use a wrong
  username in my irods environment file, the PRC throws a NetworkError while
  as a user I would expect a CAT_INVALID_USER or CAT_INVALID_AUTHENTICATION:

    CRITICAL:irods.connection:Read 0 bytes from socket instead of expected 4
    bytes ERROR:irods.connection:Could not receive server response
    NetworkException('Could not receive server response')
    ---------------------------------------------------------------------------
    StopIteration                             Traceback (most recent call last)
    File /opt/homebrew/lib/python3.13/site-packages/irods/session.py:368, in
    iRODSSession.__server_version(self)     367 try: --> 368     conn =
    next(iter(self.pool.active))     369     return conn.server_version
    StopIteration:  During handling of the above exception, another exception
    occurred:  KeyError                                  Traceback (most recent
    call last) File /opt/homebrew/lib/python3.13/site-packages/irods/pool.py:93,
    in Pool.get_connection(self)      92 try: ---> 93     conn = self.idle.pop()
    95     curr_time = datetime.datetime.now()  KeyError: 'pop from an empty
    set'  During handling of the above exception, another exception occurred:
    OSError                                   Traceback (most recent call last)
    File /opt/homebrew/lib/python3.13/site-packages/irods/connection.py:173, in
    Connection.recv(self, into_buffer, return_message, acceptable_errors)
    172 if into_buffer is None: --> 173     msg = iRODSMessage.recv(self.socket)
    174 else:  File
    /opt/homebrew/lib/python3.13/site-packages/irods/message/__init__.py:341, in
    iRODSMessage.recv(sock)     338 @staticmethod     339 def recv(sock):
    340     # rsp_header_size = sock.recv(4, socket.MSG_WAITALL) --> 341
    rsp_header_size = _recv_message_in_len(sock, 4)     342     rsp_header_size
    = struct.unpack(">i", rsp_header_size)[0]  File
    /opt/homebrew/lib/python3.13/site-packages/irods/message/__init__.py:245, in
    _recv_message_in_len(sock, size)     242     msg = "Read {} bytes from
    socket instead of expected {} bytes".format(     243         retbuf_size,
    size     244     ) --> 245     raise socket.error(msg)     247 return retbuf
    OSError: Read 0 bytes from socket instead of expected 4 bytes  During
    handling of the above exception, another exception occurred:
    NetworkException                          Traceback (most recent call last)
    File ~/git-repos/iBridges/ibridges/session.py:311, in
    Session.authenticate_using_auth_file(self)     310
    os.unlink(temp_ienv_path) --> 311     _ = irods_session.server_version  #
    pylint: disable=possibly-used-before-assignment     312 except
    NonAnonymousLoginWithoutPassword as e:  File
    /opt/homebrew/lib/python3.13/site-packages/irods/session.py:331, in
    iRODSSession.server_version(self)     329 @property     330 def
    server_version(self): --> 331     return self._server_version()  File
    /opt/homebrew/lib/python3.13/site-packages/irods/session.py:364, in
    iRODSSession._server_version(self, version_func)     363     return
    tuple(ast.literal_eval(reported_vsn)) --> 364 return self.__server_version()
    if version_func is None else version_func(self)  File
    /opt/homebrew/lib/python3.13/site-packages/irods/session.py:371, in
    iRODSSession.__server_version(self)     370 except StopIteration: --> 371
    conn = self.pool.get_connection()     372     version = conn.server_version
    File /opt/homebrew/lib/python3.13/site-packages/irods/pool.py:18, in
    attribute_from_return_value.<locals>.deco.<locals>.method_(self, *s, **kw)
    17 def method_(self, *s, **kw): ---> 18     ret = method(self, *s, **kw)
    19     setattr(self, attrname, ret)  File
    /opt/homebrew/lib/python3.13/site-packages/irods/pool.py:117, in
    Pool.get_connection(self)     116 except KeyError: --> 117     conn =
    Connection(self, self.account)     118     new_conn = True  File
    /opt/homebrew/lib/python3.13/site-packages/irods/connection.py:83, in
    Connection.__init__(self, pool, account)      82 self._client_signature =
    None ---> 83 self._server_version = self._connect()      84
    self._disconnected = False  File
    /opt/homebrew/lib/python3.13/site-packages/irods/connection.py:365, in
    Connection._connect(self)     364 # Server responds with version --> 365
    version_msg = self.recv()     367 if neg_result == USE_SSL:  File
    /opt/homebrew/lib/python3.13/site-packages/irods/connection.py:184, in
    Connection.recv(self, into_buffer, return_message, acceptable_errors)
    183     self.release(True) --> 184     raise NetworkException("Could not
    receive server response")     185 if isinstance(return_message, list):
    NetworkException: Could not receive server response

• Introduce a DataTransferInterruptedException to replace RuntimeError

  State: open
  Labels: enhancement
  Description:
  exception (if any) when a parallel put or get didn't complete. Suggest
  deprecating the RuntimeError for v4.0.0 in favor of making it a
  DataTransferInterruptedException. Originally posted by @d-w-moore
  in
  https://github.com/irods/python-irodsclient/issues/728#issuecomment-3757066726

Closed Issues – irods/python-irodsclient

• Closed on 2026-01-30:

  Store project metadata in pyproject.toml

• Closed on 2026-02-09:

  client tracks current AVU list too zealously

• Closed on 2026-01-30:

  Add GitHub Action for Python code formatter

• Closed on 2026-02-05:

  Segmentation fault and ssl errors after the client connection is cut by KeyboardInterrupt

• Closed on 2026-02-06:

  chained mutator calls from metadata manager do not preserve state

NFSRODS (irods/irods_client_nfsrods)

Open Issues – irods/irods_client_nfsrods

Closed Issues – irods/irods_client_nfsrods

icommands (irods/irods_client_icommands)

Open Issues – irods/irods_client_icommands

Closed Issues – irods/irods_client_icommands

HTTP API Client (irods/irods_client_http_api)

Open Issues – irods/irods_client_http_api

• Make the compute checksum endpoint more async friendly

  State: open
  Labels: enhancement, consortium-member
  Description:
  synchronous, which makes sense since the API layer is simply calling the
  iRODS itself that computes the hash. But, as I believe in many companies, we
  use balancers, proxies, etc. that are checking the connection itself and
  have some strict time limits on how long a session can be alive without any
  response. In our current situation, calculating a 30 GB file takes around a
  minute, so in an hour we can compute ~2 TB file at maximum. But the limits
  for sessions are often around tens of seconds, at maximum a few minutes, so
  computing anything above a few tens of gigabytes is not possible. My
  current solution is that I have added an argument that will make the
  request.post in the Python HTTP API client not to wait for a response, so it
  behaves more like an asynchronous endpoint, and after that, I'm polling the
  iCAT (iRODS object) to see if the checksum has appeared there. This is a
  "hack" to compute even large files without any timeout, as I only tell the
  API to start computing and kill the connection immediately and then poll the
  iCAT for computed checksum till it appears there. I believe this is
  functional for me, but it is kinda funky solution. Maybe implementing this
  directly in the iRODS API in some sense would be better. I wish you a good
  day. Tobias Janča, IT4I.

• Add functionality to change default application name - spOption

  State: open
  Labels: enhancement, consortium-member
  Description:
  https://github.com/irods/irods_client_library_rirods/issues/58, clients that
  depend on irods-http-api, such as rirods, should be able to update their
  default application name.

Closed Issues – irods/irods_client_http_api

PAM Interactive Auth Plugin (irods/irods_auth_plugin_pam_interactive)

Open Issues – irods/irods_auth_plugin_pam_interactive

• Absorb irods-auth-plugin-pam-interactive-client into iCommands

  State: open
  Labels: question, consortium-member
  Description:
  irods-auth-plugin-pam-interactive-client package must be installed
  separately alongside iCommands. To reduce confusion and improve user
  experience, could the relevant plugin (or relevant part of
  it)(https://github.com/irods/irods_auth_plugin_pam_interactive) be included
  in future iCommands releases?

Closed Issues – irods/irods_auth_plugin_pam_interactive

Demo Repository (irods/irods_demo)

Open Issues – irods/irods_demo

Closed Issues – irods/irods_demo

Java Client Library (irods/irods4j)

Open Issues – irods/irods4j

Closed Issues – irods/irods4j

Testing Environment (irods/irods_testing_environment)

Open Issues – irods/irods_testing_environment

• Replace use of root logger

  State: open
  Labels: enhancement
  Description: See https://docs.astral.sh/ruff/rules/root-logger-call/

Closed Issues – irods/irods_testing_environment

• Closed on 2026-02-13:

  'version' in docker compose files is obsolete

• Closed on 2026-02-04:

  RockyLinux failing with "unsupported platform: [rocky]"

• Closed on 2026-02-03:

  iRODS server log not being copied in run_unit_tests.py

• Closed on 2026-02-03:

  Problems getting python prereqs installed on 3.12.3 aka docker-compose dependency

• Closed on 2026-02-03:

  supporting docker-related Python packages now need version restrictions

• Closed on 2026-02-03:

  GitPython missing from requirements.txt

• Closed on 2026-02-03:

  Incorrect symlink name in plugin section of README

• Closed on 2026-02-03:

  Add linter workflow

• Closed on 2026-02-03:

  Testing environment tries to install irods packages in database container when --project-name argument has underscores

• Closed on 2026-02-09:

  Avoid use of apt in scripts

• Closed on 2026-02-09:

  Symbolic link in plugin directory pointing to itself causes issues in plugin install

• Closed on 2026-02-09:

  run_plugin_tests.py tries to pass logfile_path keword-argument to logs.collect_logs()

• Closed on 2026-02-03:

  Document --project-name option

• Closed on 2026-02-09:

  Plugin test runner does not clean up docker containers

• Closed on 2026-02-06:

  Almalinux 8 Docker container missing package for pgrep

• Closed on 2026-02-03:

  Document ":Z" flag requirement for xunit-viewer on RHEL

• Closed on 2026-02-09:

  Allow developers to attach a comment/note to the test run

• Closed on 2026-02-03:

  Change README to use requirements.txt in the setup process

• Closed on 2026-02-06:

  setup.py does not work as expected

• Closed on 2026-02-09:

  Make generated job names and output directories for test runs easier to find

• Closed on 2026-02-06:

  Adjust logging terminology from debug/info/warning/error

• Closed on 2026-02-06:

  Add PAM authentication support to various scripts

externals (irods/externals)

Open Issues – irods/externals

Closed Issues – irods/externals

YODA (UtrechtUniversity/yoda)

Open Issues – UtrechtUniversity/yoda

• the SRAM synchronization rule does not expect SRAM collaborations without members

  State: open
  Labels: No Labels
  Description: ### Is there an existing bug report for this?

• 
  I have searched the existing bug reports

### Current Behavior

the SRAM synchronization rule:

irule -r irods_rule_engine_plugin-irods_rule_language-instance -F /etc/irods/yoda-ruleset/tools/sram-sync.r

fails when SRAM API "get collaboration members" call return an empty response:

Jan 30 11:32:44 yoda irodsServer[3953936]: {"log_category":"rule_engine","log_level":"info","log_message":"writeString: [groups] Get members of group priv-category-add from SRAM","request_api_name":"EXEC_MY_RULE_AN","request_api_number":625,"request_api_version":"d","request_client_user":"rods","request_host":"127.0.0.1","request_proxy_user":"rods","request_release_version":"rods4.3.4","server_host":"yoda.wur.nl","server_pid":3953936,"server_timestamp":"2026-01-30T10:32:44.319Z","server_type":"agent","server_zone":"wur"}
Jan 30 11:32:44 yoda irodsServer[3953936]: {"log_category":"rule_engine","log_level":"error","log_message":"caught python exception","python_exception":"Traceback (most recent call last):\n  File \"/home/yodawur/.local/lib/python3.9/site-packages/requests/models.py\", line 976, in json\n    return complexjson.loads(self.text, **kwargs)\n  File \"/usr/lib64/python3.9/json/__init__.py\", line 346, in loads\n    return _default_decoder.decode(s)\n  File \"/usr/lib64/python3.9/json/decoder.py\", line 337, in decode\n    obj, end = self.raw_decode(s, idx=_w(s, 0).end())\n  File \"/usr/lib64/python3.9/json/decoder.py\", line 355, in raw_decode\n    raise JSONDecodeError(\"Expecting value\", s, err.value) from None\njson.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)\n\nDuring handling of the above exception, another exception occurred:\n\nTraceback (most recent call last):\n  File \"/etc/irods/rules_uu/util/rule.py\", line 92, in r\n    result = f(Context(callback, rei), *a)\n  File \"/etc/irods/rules_uu/groups.py\", line 1290, in rule_group_sram_sync\n    co_members = sram.sram_get_co_members(ctx, co_identifier)\n  File \"/etc/irods/rules_uu/sram.py\", line 314, in sram_get_co_members\n    data = response.json()\n  File \"/home/yodawur/.local/lib/python3.9/site-packages/requests/models.py\", line 980, in json\n    raise RequestsJSONDecodeError(e.msg, e.doc, e.pos)\nrequests.exceptions.JSONDecodeError: Expecting value: line 1 column 1 (char 0)\n","request_api_name":"EXEC_MY_RULE_AN","request_api_number":625,"request_api_version":"d","request_client_user":"rods","request_host":"127.0.0.1","request_proxy_user":"rods","request_release_version":"rods4.3.4","rule_engine_plugin":"python","server_host":"yoda.wur.nl","server_pid":3953936,"server_timestamp":"2026-01-30T10:32:44.350Z","server_type":"agent","server_zone":"wur"}
Jan 30 11:32:44 yoda irodsServer[3953936]: {"log_category":"legacy","log_level":"error","log_message":"executeRuleAction Failed for rule_group_sram_sync status = -1 Unknown iRODS error, Operation not permitted","request_api_name":"EXEC_MY_RULE_AN","request_api_number":625,"request_api_version":"d","request_client_user":"rods","request_host":"127.0.0.1","request_proxy_user":"rods","request_release_version":"rods4.3.4","server_host":"yoda.wur.nl","server_pid":3953936,"server_timestamp":"2026-01-30T10:32:44.351Z","server_type":"agent","server_zone":"wur"}

Notice that the same happens with other calls, for example to get the id of a SRAM member. If the call fails, for example for a HTTP error 429: too many requests, then the script crashes.

### Expected Behavior

The rule completes, skipping the "empty" collaborations or, in general, the failed SRAM calls.

### Steps to Reproduce

I am not sure why there are empty SRAM collaborations.
My guess is because after the latest Yoda upgrade, the group managers have the option to remove themselves from the group, after inviting a new member as group manager. This works fine in Yoda, but in SRAM it means that there are collaborations without members, only invited users who may or may not accept the invitation.

I am able to avoid that the rule crashes with these patches:

At line 82 in /etc/irods/rules_uu/sram.py

    response = requests.get(url, headers=headers, timeout=30, verify=config.sram_tls_verify)
    if response:
        if config.sram_verbose_logging:
            log.write(ctx, "raw response: {}".format(response))
        data = response.json()
    else:
        log.write(ctx, "raw response is None")
        data = {'collaboration_memberships': { }}

At line 314 (319 after the first patch):

    response = requests.get(url, headers=headers, timeout=30, verify=config.sram_tls_verify)
    if response:
        if config.sram_verbose_logging:
            log.write(ctx, "raw response {}".format(response))
        data = response.json()
    else:
        log.write(ctx, "raw response is None")
        data = {'collaboration_memberships': { }}

The above patches do not prevent anyway to overload SRAM API:

Jan 30 14:15:32 yoda irodsServer[3984119]: {"log_category":"rule_engine","log_level":"info","log_message":"writeString: [sram] get: https://sram.surf
.nl/api/invitations/v1/invitations/4aaa7b2d-93fc-4eaf-bb75-324825dedaf1","request_api_name":"EXEC_MY_RULE_AN","request_api_number":625,"request_api_v
ersion":"d","request_client_user":"rods","request_host":"127.0.0.1","request_proxy_user":"rods","request_release_version":"rods4.3.4","server_host":"
yoda.wur.nl","server_pid":3984119,"server_timestamp":"2026-01-30T13:15:32.075Z","server_type":"agent","server_zone":"wur"}
Jan 30 14:15:32 yoda irodsServer[3984119]: {"log_category":"rule_engine","log_level":"info","log_message":"writeString: [sram] response: 429","request_api_name":"EXEC_MY_RULE_AN","request_api_number":625,"request_api_version":"d","request_client_user":"rods","request_host":"127.0.0.1","request_proxy_user":"rods","request_release_version":"rods4.3.4","server_host":"yoda.wur.nl","server_pid":3984119,"server_timestamp":"2026-01-30T13:15:32.104Z","server_type":"agent","server_zone":"wur"}
Jan 30 14:15:32 yoda irodsServer[3984119]: {"log_category":"rule_engine","log_level":"info","log_message":"writeString: [sram] Error retrieving existing invitations: 429","request_api_name":"EXEC_MY_RULE_AN","request_api_number":625,"request_api_version":"d","request_client_user":"rods","request_host":"127.0.0.1","request_proxy_user":"rods","request_release_version":"rods4.3.4","server_host":"yoda.wur.nl","server_pid":3984119,"server_timestamp":"2026-01-30T13:15:32.104Z","server_type":"agent","server_zone":"wur"}

### Environment

- Yoda version 2.0.0

• Option to receive email notifications with additional information

  State: open
  Labels: No Labels
  Description: ### Is there an existing feature request for this?

• 
  I have searched the existing feature requests

### Is your feature request related to a problem? Please describe.

Currently, the notifications sent by Yoda via email are generic and contain very little information about the data package. In addition, to view the full contents of the notification, you need to login in to Yoda.

Some examples of these notifications:

• 'Data package secured in the vault'

• 'Data package submitted for the vault'

• 'Failed to set retry state on data package'

• 'Data package failed to copy to vault after maximum retries'

The current email notification settings do not offer much room for personalization. I can only choose to turn notifications off, or to receive an immediate email, a daily digest or weekly digest.

### Describe the solution you'd like

It would useful to receive some additional information in the notifications about the data package, This would give data managers the option to evaluate whether it is worth to logging in to Yoda or not.

Some examples of additional information that could be included to the email notifications:

• Group name

• Category

• Subcategory

• Title of the data package

• Email address of the submitter

• Size of the data package

• Date

• Etc.

### Acceptance Criteria

The feature should allow group managers to receive detailed information about the data package without needing to log in to the system, and it should also provide the option to disable these detailed notifications if they're not wanted or needed.

• Metadata error Custom license & Open data

  State: open
  Labels: consortium
  Description: ### Is there an existing bug report for this?

• 
  I have searched the existing bug reports

### Current Behavior

Combining custom license with open data leads to an error from DataCite.

### Expected Behavior

Multiple options:

• a warning or error message that it is better to add an open license (like CC-BY) to an open dataset

• a warning before publishing

• an option to specify an url with the custom license that can be used to populate the rightsURI field

### Steps to Reproduce

1. Combine the following options in Yoda default-3 metadata schema:

"Data_Access_Restriction": "Open - freely retrievable",
"License": "Custom"

1. Publish the collection, it will create the following fields in the Datacite JSON:

"rightsList": [
                {
                    "rights": "Open - freely retrievable",
                    "rightsUri": "info:eu-repo/semantics/openAccess"
                },
                {
                    "rights": "Custom",
                    "rightsUri": "https://surf-data.irods.surfsara.nl:9443/vault-etk-testing/research-etk-testing[1762524484]"                }
            ]

1. The "rightsUri" field will be populated with the Yoda web address for the Vault collection, which includes square brackets for the Unix epoch. This will lead to an error when trying to publish the dataset (tested at https://support.datacite.org/reference/post_dois):

"errors": [
    {
      "source": "rights', attribute 'rightsURI",
      "title": "DOI prefix/suffix: 'https://surf-data.irods.surfsara.nl:9443/vault-etk-testing/research-etk-testing[1762524484]' is not a valid value of the atomic type 'xs:anyURI'. at line 18, column 0",
      "uid": "prefix/suffix"
    }

### Environment

- Yoda version v2.0.0

### Additional Context

Strangely enough, there has been at least one dataset published in the past, with the same square brackets in the rightsURI in the datacite JSON: https://publication.yoda.wur.nl/full/WUR01/BSY8ZN.html
Since then, Yoda has been upgraded but as far as I can see there were no changes at the Datacite side (both metadata v4.6).
Is there a validation step in Yoda built in for the Datacite metadata? In that case, would it be an option to include a validation for this?

If you think someone else would appreciate this newsletter, they can sign up.

If you don't want to get these emails any more, you can unsubscribe here.

Four Yaks were shaved in the making of this newsletter.