ReplyLockshare

Class Description

ReplyLockShare can be invoked via the Realtime or Unified API. It allows the current Lock-Owner of a Guide to share it with anyone. Only if a request was issued via RequestLockshare the receiving user will be notified via the realtime api.

RPC Configuration

Rpc Name:

Plain: ReplyLockshare
Sha1: 8904ecf8d898030f455ff68e58f23582d326cd53

Rpc Call

RPCs can be called by their plain name or their SHA1 representation.

Rpc Parameters:

"building_id" : int,
"user_id" : int,
"approved" : bool 

Requires Login:

true

Requires Context:

Context

The context providing parameter can either be a contagt-id (8-Bytes, Alphaumeric) or an integer as a building id. The context parameter name should make the choice obviouse, the type has not to be defined manually.

true

Requires contextParamName:

building_id

Requires WriteAccess:

WriteAccess

Only accounts that have an explicit write access to the defined context can execute this RPC, no matter if the authentication level matches or not.

true

Requires AuthenticationLevel:

Context

Authentication levels allow the SuperUser to define a by-RPC granular access configuration. If RPCs are chained in a single unified call and lenient is enabled, all allowed RPCs will be executed, while execution will fail entirely with lenient set to false.

STANDARD_USER

Requires Subbuilding Merge Strategy:

SUBBUILDING_ONLY

Cache Configuration

Response Cache

All writing RPCs are not Cacheable, also Caching will be disabled by the paramters nocache and readonly.

Cache enabled:

false

Sample Request

->

{
    "building_id": 131,
    "user_id": 1,
    "approved": true
}

<-

{
    "building_id": 131,
    "user_id": 1,
    "approved": true,
    "remaining": 5
}