Ticket
allow authorized users to see cards+issues
restricted permissions on +*tform cards restricts permissions on cards that use that template - it shouldn't.
This leads to the additional problem that whoever first views the card sets the cache -- so it's fine for everyone if the first viewer has permissions, but busted for everyone if not.
allow authorized users to see cards+solution
don't check permissions on format cards for viewing cards that use that format.
allow authorized users to see cards+example
Very strange behavior - can't see most of these meeting cards even though they're set to be viewable by anyone, and they give the message "Permission error: for card Meeting+*tform: Sorry Anonymous, You don't have permission to read this card". If we really didn't have permission to see them they just shouldn't show up at all. The referenced Meeting+*type+*structure is set to be viewable only by GC Staff, but i have that role.
One Meeting card is viewable, and it is also set to be seen only by GC Staff (and when you log out that one does indeed become invisible, while the other continue to give the odd error message).
BTW, the included plus cards continue to be viewable, e.g. 2008-11-17+check-in+notes
Who:
John:
- √bang on 0.10+3 rc
- √follow-up on Wagn for RCC
- √get Ted input on usability
- Connectipedia ticketing - find notes; get a handle on what's wanted/needed; do
- do a Wagn Spokes out of Wagn 0.10 and beyond
- merge custom edit instructions into help text (and as a tag)
- clean up General+discussion (& handled stuff to Wagn+discussion+archive)
Ethan:
- communicate w board re hosting/consulting prices
- Ethan: sell to academics/foundations/social media gurus and learn from the process
how do we allow cardtype+*tform to set permissions on cardtype cards but not result in this behavior (which comes from caching first-time viewer without permission)
one option - don't check permissions to view templates
--John Abbe.....Mon Dec 01 13:57:52 -0800 2008
(If the first user who looks at a card doesn't have permissions, it was caching the "Sorry Anonymous" and then that's what others were seeing. Lewis did something that fixed the cache for those cards (and replace the Sorry Anonymous with something better), but the essential problem remains unsolved.)
--John Abbe.....Sat Dec 06 15:26:54 -0800 2008
I made it so that the attribute method accesses the cache as Wagbot, which should eliminate these problems in several situations (similar things have occurred with table of contents, for example).
--Ethan McCutchen.....Wed Apr 29 22:33:25 -0700 2009
Test on ang?
--John Abbe.....Thu Apr 30 11:08:53 -0700 2009
yep. (I'll try to note otherwise if "testing" means anything other than the ang cluster)
--Ethan McCutchen.....Thu Apr 30 11:11:55 -0700 2009
You wrote: "in several situation" - can you describe the situations where you think this won't help? (for testing / narrower ticket)
--John Abbe.....Thu Apr 30 11:17:39 -0700 2009
I used that phrase because I think the issues that it will fix are actually broader than the issue described in this card. Not just tforms, but also rforms, table of contents, edit cues...
The one situation where the fix might show is places where the cache is still in place from before my fix. My fix should prevent things from getting cached wrong in the first place. If you see a problem with older data, let me know and I'll see if clearing the cache helps.
--Ethan McCutchen.....Thu Apr 30 11:21:42 -0700 2009
will do. closing.
--John Abbe.....Thu Apr 30 11:26:34 -0700 2009
I think this should be fixed with *content and *default.
--Ethan McCutchen.....Tue May 04 16:02:56 -0700 2010