modify_data_pool_entry

You cannot modify the value with this command. To do so use "set_data_pool_entry" in OpenXPKI::Server::API2::Plugin::Datapool::set_data_pool_entry with parameter "force" instead.

This method supports two operations (which can be done simultaneously):

Rename entry (change it's key)

Pass the name of the new key in "newkey". Commonly used to deal with temporary keys.

    CTX('api2')->modify_data_pool_entry(
        pki_realm => $pki_realm,
        namespace => 'workflow.foo.bar',
        key       => 'myvariable',
        newkey    => 'myvar',
    );
    

Change expiration information

Set the new "expiration_date".

    CTX('api2')->modify_data_pool_entry(
        pki_realm       => $pki_realm,
        namespace       => 'workflow.foo.bar',
        key             => 'myvariable',
        expiration_date => 123456,
        expiration_adjust => 'newer'
    );
    

In case you pass neither an expiration nor a key update parameter the method will just touch the last_update timestamp of the item. As this is just a metadata and not used in the usual workflow logic there is no obvious reason to do so.

Parameters

• "pki_realm" Str - PKI realm. Optional, default: current realm
• "namespace" Str - datapool namespace (custom string to organize entries)
• "key" Str - key of entry
• "newkey" Str - new key (for renaming operation)
• "expiration_date" Int - UNIX epoch timestamp or OpenXPKI::DataTime relative date when the entry shall be deleted. If set undef, the entry is kept infinitely.
• "expiration_adjust" Str (newer|older|strict)

  Policy when updating the expiration_date. If set to newer, the expiration date is only updated if the given value is newer as the one already set. Same applies to older.

  strict always applies the new value which is also the default behaviour.

  Please note that with expiration_date = undef this flag is ignored.

  The adjustment rules do not interfere with newkey, so a key change is always done even if the date adjustment rules fail.

Changes compared to API v1:

Previously the parameter "namespace" was optional which was a bug.