Thanks for the suggestions Dan. This is probably misguided, but I thought it may be a plan to have a double check for view rights before loading the page. In other words check for auth.view, but if that *fails* then check for auth.invites. This will allow higher up levels of rights to remain in place and only allow invites as a fallback/addition.
I made an attempt to alter BOLTloadpage in library.php, but my php skills are sorely lacking so I could not figure out why the following does *not* work: Right at the top of the BOLTloadpage function in library.php if (function_exists('myBOLTloadpage')) return myBOLTloadpage($page, $dir, $data, $auth); if ($auth) { global $BOLTid; if (BOLTauth($page, $BOLTid, 'view') == false) { if (BOLTauth($page, $BOLTid, 'invite') == false) return; } } The file auth.invite follows the same pattern as auth.view Any thoughts? On Friday, 12 February 2016 16:37:55 UTC+2, Dan wrote: > > How secure do you want it to be? > > One solution would be to use a conditional in the header that says > something like > > [if ! inpage blueteam.roster {id} && ! inlist {p}:guest_read > {id}]<(forward action.blocked)>[if] > > You can then leaven the groups open to view for all logged in members, but > only those on the roster page or in the pages guest_read var will be able > to actually see it. Others would be forwarded away. > > The reason I ask about security is a user could go to another page they > had edit permissions on and do an include to view the contents. Because > technically they have view permissions, BoltWire would supply the page. > > I don't have an immediate solution for doing what you want to do, because > as soon as you set specific permissions for a person on site.auth.view for > a specific page, it will overwrite the general view permissions for that > group of page. I suppose you could do in your guest_read form, something > like: > > [if ! set {site.auth.view::{p}] > [command info page=site.auth.view field={p} > value={site.auth.view::{p1}.{p2}},{=newid}] > [else] > [command info page=site.auth.view field={p} value=+{=newid}] > [if] > > Basically this copies over the default group settings to the specific page > setting the first time. Afterwards, it just adds new members. The problem > is if you change the group settings you have to reset all the specific page > settings. > > Maybe someone else has a better solution... > > Cheers, > Dan > > On Fri, Feb 12, 2016 at 8:12 AM TMurNGon <tmur...@gmail.com <javascript:>> > wrote: > >> Hi Dan, >> >> I have an interesting requirement that I am not sure how to solve: >> >> Say I have a number of user groups (each with their own page hierarchy), >> for example blueteam and redteam. >> It is easy enough to set view and write access for each group in the >> current auth pages. >> >> But what if, on a page by page basis, a blue team member wanted to grant >> guest viewer or guest writer privileges to a red team member (for blueteam >> pages)? Keeping in mind that the red team normally have neither read nor >> write access to blue team pages. >> >> I'd like the blue team member to be able to add a data field with a >> specific name (guest_read? guest_write?) containing the guest users id (or >> even a guest group id); resulting in the named users or groups having read >> (and maybe write) access to the page in question. >> >> Another way would be to have some new auth pages (eg. auth.guestread or >> auth.guestwrite) which would function in a different way from the ordinary >> auth pages in that they do not completely override higher up level auths, >> but simply add the members or groups specified to the existing auths >> (auth.read and auth.write). That way the additional folks can be added >> (and later removed) without interfering with the standard setup. >> >> Not sure I have explained that sufficiently..., but I just cannot figure >> out a way to do this... >> >> Any ideas? >> >> Thank lots. >> Jan >> >> -- >> You received this message because you are subscribed to the Google Groups >> "BoltWire" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to boltwire+u...@googlegroups.com <javascript:>. >> To post to this group, send email to bolt...@googlegroups.com >> <javascript:>. >> Visit this group at https://groups.google.com/group/boltwire. >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "BoltWire" group. To unsubscribe from this group and stop receiving emails from it, send an email to boltwire+unsubscr...@googlegroups.com. To post to this group, send email to boltwire@googlegroups.com. Visit this group at https://groups.google.com/group/boltwire. For more options, visit https://groups.google.com/d/optout.