#foswiki 2014-07-03,Thu

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
***deans has left [00:57]
........................................ (idle for 3h17mn)
gac410 has left [04:14]
...................... (idle for 1h48mn)
ChanServ sets mode: +o SvenDowideit [06:02]
ChanServ sets mode: +o MichaelDaum [06:09]
....... (idle for 32mn)
ChanServ sets mode: +o CDot [06:41]
.................................. (idle for 2h49mn)
EEE53EEEHi, a question for the experts :) .... What is your personal "feeling" about adding a $text = Foswiki::Func::expandCommonVariables( $text ); in the _getACL sub within Meta.pm to enable dynamic ACL evaluation? [09:30]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Func [09:30]
EEE53EEESo that one can set ALLOWTOPICVIEW=%WHATEVER% [09:30]
MichaelDaumEEE53EEE, before you can expand common variables, the prefs and acls need to be set ... so you end up in a hen and egg problem [09:37]
EEE53EEESomehow it works [09:44]
Ok... I can get the same on directly doing $text = $this->expandMacros( $text ); instead of calling the FUNC part which creaetes a new Meta object
What about this? I think it is quite acceptable?
I have set %WHATEVER% in the WebPreferences... and on a topic I use it in ALLOWTOPICVIEW=%WHATEVER%. Whenever I change the value in WebPreferences, the topic ACL is evaluated properly
[09:55]
.... (idle for 17mn)
JulianLevensEEE53EEE: My main concern is that is may work now, but it's not officially supported. I'm in the middle of write a Store using MySQL/MariaDB and here I can optimize the SQL to include the ACL check. Dynamic ACL evaluation will make any optimization impossible
So, why do you need this capability? Why don't Groups satisfy your needs?
[10:14]
EEE53EEEFor me there are two reasons. One is based on my use cases. We have different owners of different webs and they want to protect one or many topics to certain groups. This could be done, if they would be allowed to create LDAP groups on their own. But we do not allow that. Next to that we have different workflows so that it would be beneficial to set ACL on topics to special states/phases of the workflow.
Second reason is the design of foswiki. You can use macros to get dynamic data from everywhere. So using the wiki, you feel "unlimited"... why should there be a restriction when it comes to ACLs? It is not in line with the other foswiki functions
[10:20]
.... (idle for 16mn)
JulianLevensIt may come down to choice. There is the option to replace the default ACL code with an alternative. So you choose to keep the slow and dynamic ACL access, or fast static ACL access. I am not aware that dynamic ACL access is common
I have another question: I believe with LdapContrib you can mix LDAP groups with Foswiki Groups. Could you allow some your Web owners to create Groups that merge with the LDAP groups?
I agree that a strength of Foswiki is it's ability to pick up data from anywhere, but there are common access cases (e.g. DataForms) that can have a fast access path built
It's certainly a goal to identify these cases and make it faster (not just back end but better syntax//MACROs - e.g. QuerySearch vs regex searches). Certain data access cases are obscure or simply rare are not likely to benefit from this
[10:38]
........ (idle for 38mn)
EEE53EEETo be honest, IMHO using groups is as dynamic as using macros. There is no (logical) difference in looking up members of a group (which change over time) or expanding a macro to get a userlist from another source. Anyhow I will go the route with wiki groups in addition to LDAP groups to not go too far away from the "original" wiki code. [11:23]
jastarbitrarily dynamic access rules are much harder to cache, though [11:26]
MichaelDaum^like [11:39]
foswiki_irc1Hello - has anyone an idea why %SEARCH type="query" is per Defauilt case-sensitive and how to change ist? I tried casesensitive="off" but it does not work.
I use it to search for metadat in a topic.
Relevant querypart looks like: %SEARCH{ type="query"
"form.name = 'MyDataForm' AND Company ~ '*%URLPARAM{"searchinput" encode="quote"}%*'
i also tried using regxsearch with =~ but i do not know how to add the /i modifier. i.e. /myregex/i dos not work.
[11:53]
would say thank you to any hint that guides me into the right direction ;-) [12:06]
........ (idle for 37mn)
JulianLevensfoswiki_irc1 (?i:myregex) should work [12:43]
***ChanServ sets mode: +o Lynnwood [12:43]
dgretch has left [12:52]
ChanServ sets mode: +o gac410 [12:59]
foswiki_irc1Hi anyone having an idea why %SEARCH{ type="query" "form.name = 'MyDataForm' AND Company ~ '*%URLPARAM{"searchinput" encode="quote"}%*' is always case sensitive. even when setting casesensitive="off" i dont get it.
p.s sould find metadata in a topic, but only finds them case-sensitive...
[13:01]
JulianLevensfoswiki_irc1 (?i:myregex) should work
for a regex search anyway
[13:04]
foswiki_irc1i tried it using regex like this: Company =~ '/.*%URLPARAM{"searchinput" encode="quote"}%.*/i' but this does not work
i do not know where / how to set the regex modifier "i"
a standard regex would look like: /myregex/i
[13:05]
gac410foswiki_irc1: Julian has answered twice now. (?i:yourregex) is also standard [13:07]
foswiki_irc1ssry havent seen this - and thank you julian. do you mean: '?i:.*%URLPARAM{"searchinput" encode="quote"}%.*' [13:08]
gac410It has to be within parenthesis. The (?xxx: ) were xxx are the regex modifiers. [13:09]
foswiki_irc1i ll try it now [13:10]
gac410From the perl RE reference, the complete definition is:
(?pimsx-imsx:...) Enable/disable option (as per m// modifiers)
foswiki_irc1: The other way to do this is to use the "lc" - lowercase operator. and apply lc to the left and right sides of the test.
[13:13]
JulianLevensDo the docs cover these options? It must be a pretty common usage [13:18]
gac410See Foswiki:System.QuerySearch [13:18]
FoswikiBothttp://foswiki.org/System.QuerySearch [ QuerySearch ] [13:18]
gac410Includes an example:
%SEARCH{"(lc(Shades)='green' OR lc(Shades)='yellow') AND NOT(lc(Shades) ~ 'brown')" type="query"}% 
I have to admit, honoring the casesensitive option would be nice. but the query search code is not anything I want to work on.
[13:18]
JulianLevensI think the regex alternative should be suggested as an alternative. That will also be unicode aware. We could also add an fc option to query search to match the perl equivalent http://perldoc.perl.org/functions/fc.html
I think the problem with the casesensitive option for query search is that you probably want fine grained control
[13:22]
foswiki_irc1Thanky you Julian - it works perfect.
about the docs. No they do not cover this. I treid as a last resolut to work with ethe spreadsheet plugin. and its $LOWER function.
[13:27]
gac410I agree it could use more emphasis, but Foswiki:System/QuerySearch does document the "lc" operator and gives examples of it's use [13:30]
FoswikiBothttp://foswiki.org/System/QuerySearch [ QuerySearch ] [13:30]
foswiki_irc1the lowercase operarotr is also a good idea. Did not know that it exists though. (That why i tried %CALC($LOWER)) [13:30]
gac410Julian, I'll try to update QuerySearch docs to add a note on how to do case insensitive searching. [13:34]
foswiki_irc2Hi guys! I'm currently setting up an intranet wiki as a student job, we'd primarily use it as an information database. I was wondering how friendly foswiki was? After my job is done, other people will continue to make the wiki live, and they might not be tech geniuses. thanks! [13:35]
gac410The fc option ... we'd have to write our own for perl versions prior to 5.16
foswiki_irc2 foswiki is like many things. simple on the surface, but can get very complex as you dive deeper.
If your users develop wiki applications, with data forms, etc. it needs some good technical knowledge. As a simple wiki for straight forward page editing, it's relatively simple.
[13:35]
JulianLevensYes I think fc is out and as (?i:xxx) is unicode aware that is a very good alternative. There will be the caveat that it will be as unicode aware as the underlying perl [13:38]
foswiki_irc2Thanks for the info, I think I'll go ahead with foswiki [13:39]
gac410JulianLevens: So for the VarSEARCH topic, I'm adding:
casesensitive | ... (Not applicable for =type=query= searches. QuerySearch is always case sensitive.)
[13:43]
JulianLevensGood, I think that's the right choice [13:44]
foswiki_irc1Yepp a note on the docs aboiut this would be really helpful. [13:46]
JulianLevensgac410: I think on reflection it needs to be more like | (For =type=query= searches this is always globally "on" as QuerySearch has more flexible casesensitive options of it's own) | [13:51]
gac410okay ... will do [13:51]
JulianLevenss/globally// [13:52]
gac410| Case sensitive search. (For =type=query= searches, =casesensitive= is always ==on==. See QuerySearch for more flexible options.) | [13:54]
JulianLevens:) [13:54]
btmanhi, a new fowiki user here. Desperately seeking how to change to Natskin :-/ [13:55]
gac410JulianLevens: There is a warning in our Regex docs: You can use more advanced features of Perl regular expressions, but your searches are not guaranteed to be supported on all Foswiki configurations, for example where a database store is in use and the database doesn't support the full Perl syntax for REs.
Do you know how this will apply to (?i:...)
[13:59]
JulianLevensAlas, mostly not [14:00]
gac410That's what I was afraid of. ... I think it might be best not to document the (?i:...) usage then and stick with the lc / uc [14:01]
JulianLevensI think that's all we can do for now. It will need revisiting though
if someone needs unicode aware case insensitive tests maybe there should be another topic for that
[14:03]
gac410That will have to be deferred to a foswiki Unicode release. Once we get 1.2 out. If we can manage to get some committed developers. [14:05]
foswiki_irc1If i would like to use the lc() variant, how would it look like in this example?: %SEARCH{ type="query" "form.name = 'MyDataForm' AND Company ~ '*%URLPARAM{"searchinput" encode="quote"}%*' [14:07]
JulianLevenslc(Sparkasse) != lc(Sparkaße) but a proper case insensitive check should work [14:07]
foswiki_irc1would tzhis be correct: %SEARCH{ type="query" "form.name = 'MyDataForm' AND lc(Company) ~ '*lc(%URLPARAM{"searchinput" encode="quote"}%)*' [14:08]
JulianLevens%SEARCH{ type="query" "form.name = 'MyDataForm' AND lc(Company) = lc(%URLPARAM{"searchinput" encode="quote"}%)"
Or something close to that anyway
[14:09]
gac410foswiki_irc1 or ~ lc('*%URLPARAM{"searchinput" encode="quote"}%*') [14:10]
foswiki_irc1ok - i am not always sure when one can use those function and when they will conflict with a macro expansion...^^ [14:10]
gac410I think the lc needs to be outside of your quotes, but I'm not sure.
Macro expansion is always inside-out left-right.
So URLPARAM expands FIRST, and then the %SEARCH is interpreted.
[14:10]
foswiki_irc1ah i see [14:11]
gac410Here is an example from our FAQ search ... for a case insensitive regex search: "lc(name)=~lc('.*%URLPARAM{"q"}%.*')" [14:18]
..... (idle for 22mn)
GithubBot[foswiki] FoswikiBot pushed 1 new commit to master: http://git.io/xrsDyg
foswiki/master 053c5a2 GeorgeClark: Item9693: Document case sensitivity of query search...
[14:40]
***GithubBot has left [14:40]
FoswikiBothttp://foswiki.org/Tasks/Item9693 [ Item9693: Documentation updates for Foswiki 1.2.0 ] [14:40]
gac410foswiki_irc1: http://git.io/xrsDyg shows what will go into the documentation for the next release. Hopefully this clarifies the case sensitivity and use of lc/uc in query search [14:43]
.......................................... (idle for 3h27mn)
***dgretch has left [18:10]
.......... (idle for 48mn)
ChanServ sets mode: +o Lynnwood_ [18:58]
.................. (idle for 1h27mn)
GithubBot[foswiki] FoswikiBot pushed 1 new commit to master: http://git.io/6uadjA
foswiki/master 767f643 GeorgeClark: Item9693: Typo in PreferenceSettings on parent meta...
[20:25]
***GithubBot has left [20:25]
FoswikiBothttp://foswiki.org/Tasks/Item9693 [ Item9693: Documentation updates for Foswiki 1.2.0 ] [20:25]
......................................... (idle for 3h22mn)
***gregg4567 has left [23:47]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)