I don't really understand what this is about, but aren't all the templates overriddeble from the Skin? Anyway, I wouldn't want to have an additional virtual user.
Thanks, Caty On Wed, Oct 5, 2016 at 7:03 PM, Eduard Moraru <[email protected]> wrote: > +1 for 1), with the reminder that filesystem templates are considered to be > managed/authored by the superadmin, while Skin template overrides will be > managed/authored by the Skin document's author, so overriding a template > from a skin will not give you superadmin author rights. > > Thanks, > Eduard > > On Wed, Oct 5, 2016 at 12:29 PM, Thomas Mortagne < > [email protected]> > wrote: > > > Hi devs, > > > > Right now (and since forever) the default behavior for templates is to > > be executed with the right of the current document content author > > (it's not really explicit, it's just how PR works when there is no > > sdoc). This means that unless you explicitly indicate an author for > > your template (possible since 7.x) you don't really have any idea > > which right it's going to have at runtime. It also make harder to > > properly execute templates outside of main rendering thread where the > > "current document" often don't really make much sense. > > > > I think we should make the default more stable. > > > > I can think of two possibilities: > > > > 1) with what we got right now the only real possibility is to execute > > the filesystem template with superadmin right (which is only an option > > right now). Makes it consistent with the "code is executed with the > > right of its author" rule we have for wiki pages > > 2) introduce some new virtual user (like "templateauthor" or > > "scripter" or whatever) which only have script right and use that as > > filesystem template author if we absolutely want template to not have > > too many rights by default (even if modifying a filesystem template > > require much more access than superadmin in practice) > > > > +1 for 1) > > > > -- > > Thomas Mortagne > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
