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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
