[Sputnik-list] Permissions

[Yuri Takhteyev]

>  In line 462, I changed "order = tostring(math.random()*5)," to
>  "order = string.gsub (tostring(math.random()*5), ",", "."),".
>  I think this error is because the locale, as in Brazil is common
>  to write a "," instead of a "." when representing a float point
>  number.

Ouch.  I am glad you managed to track this down.  But I am wondering
if this is the best way to fix it.  Does Lua have some sort of
local-independent version of to_string that would be appropriate for
converting numbers to stings to dostring them later?

BTW, I apologize for the magic number "5" in there.  The worst part is
that it took me a while to remember what it stands for...  So, really,
I think this should be:

order= local_independent_tostring(math.random()*max_order)

where max_order = the maximum order value among the "real" fields

BTW, what this all is for is to put honeypot fields in random
positions.  Basically, each field definition has a parameter called
"order" which use used to order the fields.  This helps if you want to
insert a custom field at a specific position:

E.g. @Root says:

edit_ui = [[
...
page_params_hdr = {1.0, "header"}
page_name       = {1.1, "readonly_text"}
title           = {1.2, "text_field"}
show_advanced   = {2.0, "show_advanced", no_label=true}
category        = {2.1, "text_field", advanced=true}
...
content         = {3.1, "big_textarea", rows=27,  no_label=true}
...
]]

For the "tickets" plugin, we want to insert a bunch of custom fields
between "permissions" and "content".  We do this with:

edit_ui= [[reported_by = {1.31, "text_field"}
severity    = {1.32, "select", options={"unassigned", "show stopper",
"annoying", "cosmetic"}}
priority    = {1.33, "select", options={"unassigned", "highest",
"high", "medium", "low", "lowest"}}
status      = {1.34, "select", options={"new", "confirmed",
"assigned", "fixed", "tested", "wontfix"}}
...
]]

Note that those fields will show up between "Title" and all the
"Advanced" fields because their "order" falls in between 1.2 ("title")
and 1.3 ("advanced_fields").

>  But about the "Create repository" step, maybe would
>  be better if Sputnik checked if the repository exists
>  instead of Versium. When using LFS, wiki-data is created by
>  the Sputnik script, not by Versium.

Well, I don't want Sputnik to have to know that it's using one or the
other storage implementation.  Note that with storage.simple, the
wiki-data directory is created by the sputnik _installation script_
not by Sputnik itself.

In other words, I think versium storage implementations should ideally
be able to initialize themselves upon first use, but if they can't,
the user should be instructed to perform some sort
implementation-specific installation steps, which would ideally just
involve running a script.  In either case, though, Sputnik assumes
that the storage implementation is either ready to go or will
initialize itself when called the first time.

The reason versium.storage.simple doesn't create the directory is
because Sputnik might not always have permissions to do that.  The
installation script is presumably being run by the user who is allowed
to create directories and can set permissions on that directory to
make it writeable by the server.  I am guessing the same logic might
apply to the svn implementation, so maybe making a simple
initialization script is the way to go.

>  I did not understand why you prefer "luarock install versium-svn"
>  instead of just ""luarocks install luasvn".
>  What would be the benefits?

It's was meant as question really.  But I think it would make plugins
easier to understand.  Basically, if you want to install a versium
plugin X, you do "luarocks install versium-x".  I.e.: "luarocks
install versium-svn", "luarocks install versium-sqlite", "luarocks
install versium-s3", etc.  It would always be one rock which would
pull whatever else it needs.  If we say that to install the SVN plugin
you need to install "luasvn" and assume that versium.storage.svn is
already there, then this leaves you wondering what you need to install
for versium.storage.sqlite.  Do you need luasql?  Is
"versium.storage.sqlite" included? Etc.  Plus this makes it easy to
know when and what to upgrade.  E.g., you would know to ignore any new
releases of "versium-sqlite".  But again, it's a question.  Do you
think I am being a decomposition freak?

- yuri