There is an option auto-authorize that allows you to automatically authorise requests, see https://docs.tigase.net/tigase-server/master-snapshot/Administration_Guide/html/#autoSub (if this link doesn't work yet use this one and scroll a bit down.

However, if you manage roster externally then using Dynamic Rosters seems like a better idea.

Hmm I updated the configuration accordingly, but still I am getting a rooster with type="subscribe" in the Tigase UI client I am receiving the popup with question to accept the contact invitation.

This is because... there was an error in the documentation :-)

A while back we decided to split presence plugin into two for efficiency: one responsible for handling subscriptions (presence-subscription) and state (sharing presence information depending on the state: presence-state). Old presence plugin is still there but it's not enabled by default and if you used configuration from the documentation then 'auto-authorize' = 'true' would not be enabled for correct, active plugin. You should use:

'sess-man' () {
    'jabber:iq:roster' {
        'auto-authorize' = 'true'
    }
    'presence-subscription' () {
        'auto-authorize' = 'true'
    }
}

I just check it and it works as expected:

U1 sends:

<presence type='subscribe' to='tigase2@atlantiscity'/>

U1 recives:

<iq type="set" to="tigase1@atlantiscity/Psi+/2" id="rsttig5">
    <query xmlns="jabber:iq:roster" ver="15a2ec55b9eed0485d6da92f487d547a">
        <item subscription="both" name="tigase2" jid="tigase2@atlantiscity"/>
    </query>
</iq>

<presence from="tigase2@atlantiscity/Psi+" to="tigase1@atlantiscity">
    <priority>55</priority>
    <c xmlns="http://jabber.org/protocol/caps" node="http://psi-dev.googlecode.com/caps" ver="0.16" ext="cs e-time ep-notify-2 last-act mr sxe whiteboard"/>
</presence>

U2 recives:

<iq type="set" to="tigase2@atlantiscity/Psi+" id="rsttig4">
    <query xmlns="jabber:iq:roster" ver="2c801cc687581d9263dea90e5b873cfd">
        <item subscription="both" name="tigase1" jid="tigase1@atlantiscity"/>
    </query>
</iq>


<presence from="tigase1@atlantiscity/Psi+/2" to="tigase2@atlantiscity">
    <priority>64</priority>
    <c xmlns="http://jabber.org/protocol/caps" node="http://psi-dev.googlecode.com/caps" ver="0.16" ext="cs e-time ep-notify-2 last-act mr sxe whiteboard"/>
</presence>

Hah :) thanks it worked. Should I raise a request to update documentation or that defect is enough ?

It was already fixed yesterday https://github.com/tigase/tigase-server/commit/af8116e654a3cf98ba7d801499cdebfa54ca8a3b :-)

Hi again :)

It works fine when I am sending a stanza like you shown. However We decided to move the connecting the users to Server to be invoked at given scenarios.

In our BE we are trying to send the HTTP request with proper stanza: So I am sending a request to: POST /rest/stream/?api-key=our-api-key with body:

<presence type="subscribe" xmlns="jabber:client" from="fromUser@ourhost.com" to="toUser@ourhost.com" />

I am receiving 200, and the following happens:

toUser receives rooster with subscription like in your above message, but just after that he receives also rooster but subscription is set to from instead both:

<iq type="set" to="toUser@ourhost.com" id="rsttig4">
    <query xmlns="jabber:iq:roster">
        <item subscription="from" name="fromUser" jid="fromUser@ourhost.com"/>
    </query>
</iq>

About the fromUser he receives subscription="none"...

It looks like a stanza I sent through REST is interpreted differently the one I send in the UI client. Should I know anything more about the REST call?

REST requests are not processed by fromUser but are injected on the server-side as if they were received, ie. from the remote server, so fromUser's roster is not aware of <presence/> stanza sent by you using REST request and that stanza was delivered only to toUser.

Due to thatfromUser in roster has subscription set to none and toUser has in roster subsription set to from.

Hmm so how can I manage it? Can I send second stanza setting to="fromUser" ? Do you have any hints?

Well, I think that sending presence stanzas to both users (so that both users would be aware of that) could be possible, but it is possible that it may not be possible if some presence sent from the account owner to the server would be required.

However, if both users accounts are on your own server you could check user-roster-management and user-roster-management-ext ad-hoc commands as they were designed for manipulation of users roster by the server on the user's behalf.

I checked these commands and although the response returns information that operation was successful there is no change in roster list... Fortunately if I run roster-fixer command it seems to work. I will confirm that