I don't believe it will work to put markup in the site.auth pages. So
{member} won't work. But write permissions of

login.*: @owner

should do roughly the same thing. I'm not sure it applies to
subhierarchies though. Like login.caveman.somepage. I'll have to check
that they have ownership of the whole domain.

We've explored the idea of allowing limited markup in site.auth pages,
but haven't yet, mostly because of concerns about performance and
complexity. But we could if necessary consider some minimal
capabilities if there was a clear need.

At the very least we could have a simple, fast string replacement for
{id}. I'll look into that.

Can you think of other markup you would specifically like to see
recognized in a site auth page? Conditionals? some kind of functions?
It opens up crazy possibilities, but there is a balance between crazy
possibilities and confusion. If you know what I mean...  And I'm all
for speed, speed, speed...

Cheers,
Dan


On Wed, Sep 23, 2009 at 7:14 AM, Markus <[email protected]> wrote:
>
> Hi,
>
> I want to allow members to edit their member page (and maybe
> subpages). I read the "Member Profiles" paragraph on
> docs.concepts.members but then I wondered...
>
> Why isn't it possible to allow member pages via site.auth?
>
> Like "login.{member}*: @owner" for write access and "login.*: @member"
> for viewing.
>
> Regards, Markus
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"BoltWire" 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/boltwire?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to