Late here, so I haven't digested this mail yet. I just wanted to mention that I ported the attachment module (and specifically the Wiki view of attachments). This should be sufficient proof of concept I think, before merging.
As for extra permissions for attachments, etc. I'd prefer to wait until post-merge, to keep the patch at a minimum. Also, I rewrote authz_policy. It supports access controls down to the version of a resource. It uses configobj because ordering is critical when matching rules and ConfigParser does not preserve order :(. It's also nice, simple and concise too, which is good for a "sample" plugin. Details in the doc string. On 5/25/07, Christian Boos <[EMAIL PROTECTED]> wrote: > > Alec Thomas wrote: > > On 5/24/07, Christian Boos <[EMAIL PROTECTED]> wrote: > > > >> I haven't tested the branch yet, but looking at the changes, it seems good. > >> What I'd like to try out before the WE would be to bring the > >> /sandbox/security up to date with trunk and your newer > >> /sandbox/pycon/security branch, using your approach. > >> > > > > I don't understand what the purpose of this would be. The branches > > have diverged sufficiently that merging them would gain no benefit and > > much pain. > > > > The older branch had some more features w.r.t to ticket permissions, > attachment permissions, timeline and search support. > I actually did the merge locally and I'll keep the diff with the pycon > branch around, as a kind of checklist for later. > > > >> As usual, I want to check whether the approach is good enough for > >> handling fine grained ticket permissions and attachment permissions. > >> > > > > The system is functionally equivalent, it's just the method of > > accessing the policy that has changed. The context object is still > > passed to the policy, with all the information that provides > > (attachment parent resource, etc.). In that respect, nothing differs > > from the old branch. > > > > OK. On a somewhat related note, I also wanted to follow-up with the > ResourceDescriptor / RenderingContext split I discussed with you the > other day on #trac. > > The "parent" notion in particular would gain from such a split: > - some resources have a "parent" resouce if they're not existing > outside of the scope of that resource and if they need to be deleted > when the parent resource gets deleted. Typically this is the case for > attachments. We could imagine having this for comments in the future. > - the rendering context "parent" is used to represent the nesting of > rendered content (a wiki fragment of a resource rendered inside another > wiki resource) > > The ResourceDescriptor correspond to the specification of "what" is > accessed, and the RenderingContext represents "how" the view should be > rendered (how URLs should be formed, what the expected output mime-type > is) and finally the req represents the "who" part. The existing wiki > context can still be used to encapsulate all those aspects > (ctx.descriptor, ctx.rendering, ctx.req fields). > > Further refinements of the permission policy could eventually make use > of the resource descriptors more directly instead of using hash(context). > > -- Christian > > > > -- Evolution: Taking care of those too stupid to take care of themselves. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
