1 2012-06-27T00:33:20 *** dwcramer
2 2012-06-27T01:24:12 <spy> ThomasWaldmann: http://dpaste.com/763993/
3 2012-06-27T01:25:16 <spy> ThomasWaldmann: when we add a lot of items (in this example more than 7) without field 't2' then 't2' becomes an unsortable field
4 2012-06-27T01:27:11 <spy> ThomasWaldmann: we should do ix.optimize() and after that we will be able to sort by that field
5 2012-06-27T01:37:11 <spy> so, when we restore our data from the serialized file no one item contains 'ptime' meta. That is why our blog posts would be unsortable. In order to make the sorting by 'ptime' working we should add some item with 'ptime' meta and after that execute 'moin index-optimize'.
6 2012-06-27T01:47:55 *** spy
7 2012-06-27T02:02:04 *** dwcramer
8 2012-06-27T03:34:46 *** sudo_dirk1
9 2012-06-27T03:35:57 *** sudo_dirk
10 2012-06-27T05:41:27 *** dwcramer
11 2012-06-27T05:57:47 <xiaq> hm, how is the wikiname meta key used?
12 2012-06-27T05:58:01 <xiaq> or rather, what will happen if i change wikiname of an item?
13 2012-06-27T06:12:09 <bretonium> ThomasWaldmann: that's not that easy :) this will require a linear search for each branch
14 2012-06-27T06:17:38 <bretonium> also, what ACLs does a fork revision have?
15 2012-06-27T07:17:01 <bretonium> also, y u no use unix-like permissions?
16 2012-06-27T07:38:33 <bretonium> what are the typical usecases for hierarchical items and hierarchical ACLs?
17 2012-06-27T07:53:58 <dreimark> moin
18 2012-06-27T07:54:20 <bretonium> moin
19 2012-06-27T07:54:46 <dreimark> xiaq: the name is an alias to the uuid
20 2012-06-27T07:55:00 <dreimark> it is the represenatation of that
21 2012-06-27T07:58:24 <dreimark> bretonium: hacl are used if you have a dependency of items and you don't want to write permissions on each item
22 2012-06-27T08:09:09 <bretonium> ThomasWaldmann: http://etherpad.osuosl.org/moin2-bms 174+
23 2012-06-27T08:09:33 <dreimark> a typical usecase is that a common user has no admin rights to setup own acls
24 2012-06-27T08:10:13 <dreimark> so if you confuso you can create a item for him having acls
25 2012-06-27T08:10:29 <dreimark> s/confuso you/
26 2012-06-27T08:10:58 <dreimark> all subitems will have the same acls
27 2012-06-27T08:11:51 * dreimark has a slow wifi connection currently
28 2012-06-27T08:16:13 <bretonium> possible solution for hierarchical ACLs: if this.branch in self.lower.list_of_branches: inherit permissions from self.lower.branches[this.branch].head
29 2012-06-27T08:16:22 <bretonium> else: inherit self.lower.branches["master"].head perms
30 2012-06-27T08:16:33 <bretonium> and store all ACLs in "all" index
31 2012-06-27T08:26:22 <dreimark> have you thought on methods to merge acls if a braanch becomes removed, merged, etc.?
32 2012-06-27T08:29:01 * dreimark has the feeling that hacl should not be a config option, also we have to check other acl settings currently defined in config
33 2012-06-27T08:29:27 <dreimark> may be we better have an intial root item
34 2012-06-27T08:29:29 <bretonium> branches and ACLs have nothing to do with each other and are used for determing hierarchical ACLs only. ACLs are stored in revisions. When merging we could ask the user, which branch heads ACLs to use
35 2012-06-27T08:29:43 <dreimark> not the setting
36 2012-06-27T08:30:29 <bretonium> *branch head's
37 2012-06-27T08:30:55 <dreimark> http://hg.moinmo.in/moin/2.0/file/aa79e8413d9c/wikiconfig.py#l36
38 2012-06-27T08:31:31 <dreimark> you define there if you want hacl instead of acl
39 2012-06-27T08:32:26 <dreimark> bretonium: who merges?
40 2012-06-27T08:32:34 <bretonium> bretonium: user
41 2012-06-27T08:32:41 <bretonium> dreimark: ^
42 2012-06-27T08:33:00 <dreimark> he can only merge the stuff he has read rights
43 2012-06-27T08:33:37 <bretonium> right. And if can't merge, the new revision will not be created, nothing to do here.
44 2012-06-27T08:33:49 <dreimark> he should not get items to read he has no rights in one branch
45 2012-06-27T08:34:25 <dreimark> ok
46 2012-06-27T08:35:50 <dreimark> so, two problems, a user never can merge or some stuff is not mergable and the branch merge is only partial
47 2012-06-27T08:37:04 <dreimark> ThomasWaldmann: ideas on that ^
48 2012-06-27T08:48:26 <dreimark> bbl
49 2012-06-27T08:53:32 <ronny> lets be clear, full wiki merge is a inherently broken concept, it cannot possibly work for anything bigger than toys
50 2012-06-27T08:53:50 <ronny> merge can only work per item
51 2012-06-27T08:54:02 <ronny> and there we know stuff
52 2012-06-27T08:54:26 <bretonium> how does "full wiki merge" differ from "one item merge"?
53 2012-06-27T08:54:42 <ronny> bretonium: involves sets of items
54 2012-06-27T08:54:55 <ronny> bretonium: but users dont necessaryly have the perms
55 2012-06-27T08:55:00 <ronny> you can only do what you can do
56 2012-06-27T08:55:35 <ronny> lets not have a builtin construct that can partially fail due to permissions
57 2012-06-27T08:56:09 <bretonium> I don't think that "full wiki merge" will be done by someone except administrator
58 2012-06-27T08:57:35 <ronny> also its very likely that it can fail to scale
59 2012-06-27T08:58:00 <ronny> (imagine a case where a few hundret items need review and maybe manual merging
60 2012-06-27T08:58:43 <bretonium> what does it have to do with current discussion? Or it's a separate one?
61 2012-06-27T08:59:12 <ronny> merging of subsets works in face of permission degradion and what users can handle one at a time
62 2012-06-27T08:59:23 <ronny> also note that subsets may be the full set
63 2012-06-27T08:59:48 <ronny> so you get "full" merges for free if you can do them, but you are entirely fine if you cant
64 2012-06-27T09:03:40 <ThomasWaldmann> xiaq: wikiname is the name of the WIKI, it is for wiki farms (multiple wikis at one site) and identifies the wiki
65 2012-06-27T09:04:23 * ThomasWaldmann doesn't have time now to review any stuff, will likely be rather busy today
66 2012-06-27T09:04:56 * ThomasWaldmann bbl
67 2012-06-27T09:05:03 <bretonium> aww
68 2012-06-27T09:05:57 *** yufra
69 2012-06-27T09:06:55 *** yufra
70 2012-06-27T09:52:23 *** jaiditya
71 2012-06-27T10:00:20 <jaiditya> moin
72 2012-06-27T10:06:52 *** jaiditya
73 2012-06-27T10:31:41 *** spy
74 2012-06-27T10:36:17 *** jaiditya
75 2012-06-27T10:44:49 *** jaiditya
76 2012-06-27T11:23:19 *** greg_f
77 2012-06-27T11:28:23 *** jaiditya
78 2012-06-27T11:30:43 *** kanha_
79 2012-06-27T11:31:38 *** kanha
80 2012-06-27T11:48:44 <dreimark> re
81 2012-06-27T13:38:54 *** spy_
82 2012-06-27T13:39:17 *** spy
83 2012-06-27T13:44:23 *** spy__
84 2012-06-27T13:45:20 *** spy_
85 2012-06-27T13:57:52 *** dave_largo
86 2012-06-27T14:09:23 *** kanha_
87 2012-06-27T14:10:05 *** kanha
88 2012-06-27T15:06:02 *** jaiditya|2
89 2012-06-27T15:09:22 *** jaiditya
90 2012-06-27T16:19:44 <spy__> ThomasWaldmann: hi, did you see my tests? http://moinmo.in/GoogleSoc2012/WikiBlog/2012-06-26
91 2012-06-27T16:20:00 *** jaiditya|2
92 2012-06-27T17:57:06 *** RogerHaase
93 2012-06-27T19:02:30 <dreimark> spy__: yes, but he is busy today
94 2012-06-27T19:02:49 <dreimark> 09:06 * ThomasWaldmann doesn't have time now to review any stuff, will likely be rather busy today
95 2012-06-27T19:03:22 <dreimark> have you filed an issue to whoosh tracker
96 2012-06-27T19:03:25 <dreimark> ?
97 2012-06-27T19:28:55 <spy__> dreimark: not yet, I was not sure that this is a bug. Ok will write to whoosh developers now
98 2012-06-27T19:58:43 *** greg_f
99 2012-06-27T20:14:15 <dreimark> spy__: just discuss it with him
100 2012-06-27T20:14:20 <dreimark> bbl
101 2012-06-27T20:15:46 <spy__> I wrote on ##whoosh channel
102 2012-06-27T20:15:59 <spy__> still no response
103 2012-06-27T22:22:42 *** dave_largo
104 2012-06-27T22:31:46 <ThomasWaldmann> re
105 2012-06-27T23:59:35 *** technossomy
106
MoinMoin: MoinMoinChat/Logs/moin-dev/2012-06-27 (last edited 2012-06-26 22:45:04 by IrcLogImporter)
