Adds description of `lua_call option specifics
#5149
Conversation
* ``lua_call`` option allows the specified user to perform the specified lua function on the instance * permissions can be granted to any user registered on the instance * ``lua_call: [all]`` grants access to all global Lua functions except built-in ones * grants are valid until instance is rebooted * Fixes 4552
github-actions
bot
temporarily deployed
to
branch-gh-4552-runtime-access-to-lua-functions
github-actions
bot
temporarily deployed
to
branch-gh-4552-runtime-access-to-lua-functions
github-actions
bot
temporarily deployed
to
branch-gh-4552-runtime-access-to-lua-functions
github-actions
bot
temporarily deployed
to
branch-gh-4552-runtime-access-to-lua-functions
| .. _configuration_reference_lua_call: | ||
|
|
||
| .. confval:: lua_call |
There was a problem hiding this comment.
Is it on the top level? The deployment fails, so I can't check how it is rendered.
| Since version :doc:`3.3.0 </release/3.3.0>`, the ``lua_call`` option allows the specified user to perform the specified lua function on | ||
| the instance during runtime. |
There was a problem hiding this comment.
Perform the Lua function? I guess you tell about granting a permission to call it, not about the call itself.
| Since version :doc:`3.3.0 </release/3.3.0>`, the ``lua_call`` option allows the specified user to perform the specified lua function on | ||
| the instance during runtime. |
There was a problem hiding this comment.
'During runtime' and 'in runtime' feels a bit different. The first is just 'when the instance is run', but 'in runtime' may mean 'without persistence'. Maybe the formal documentation should use less informal words.
| Note that the special option ``lua_call: [all]`` is also supported, granting access to all global Lua functions except built-in ones, | ||
| bypassing database restrictions. |
There was a problem hiding this comment.
Imagine I've no needed context: it seems I have no chance to understand what does 'database restriction' mean.
| Note that the special option ``lua_call: [all]`` is also supported, granting access to all global Lua functions except built-in ones, | ||
| bypassing database restrictions. | ||
|
|
||
| After the instance is rebooted, permissions defined via the ``lua_call`` options are reset to the values stored in the database. |
There was a problem hiding this comment.
Hmm. We discussed that and it is correct to some extent. However, the permissions that are granted using lua_call via the YAML config are both runtime and persistent. It is possible that we have no RW instance at the moment and the permission is not persisted, right. But usually it is persisted and read from the data files after restart.
Don't know how to better formalize it.
|
It seems, we should work together here to provide a correct formal description. It would be nice to give a concise, but easy to understand explanation. |
lua_calloption allows the specified user to perform the specified lua function on the instancelua_call: [all]grants access to all global Lua functions except built-in ones