Regarding the right way to address these exceptions, I don't have much  
of a comment.  Whatever you and Tres decide.

--Paul

On Apr 17, 2009, at 11:35 PM, Shane Hathaway wrote:

> I get a lot of exceptions when I try to navigate this part of a site.
> The exceptions happen because ISecurityWorkflow.setInitialState() is  
> not
> being called for some objects.
>
> We could clean this up by having the application use annotations  
> instead
> of setting a magic attribute named 'security_state'.  Also, we could
> call setInitialState() from an event subscriber listening for
> IObjectAddedEvent or IObjectCreatedEvent.
>
> Anyway, I'm not going to finish this in time for m10.
>
>
> ** Changed in: karl3
>       Status: New => In Progress
>
> -- 
> Suppress Is Private in intranets
> https://bugs.launchpad.net/bugs/360555
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Porting KARL to a new architecture: In Progress
>
> Bug description:
> Hide the Is Private box on add/edit forms in an office.
> Background
> =============
>
> We have "tools" in communities for managing content.  It's pretty  
> nice: you can extend KARL simply by making a new tool.  Each tool  
> can manage content types it defines (or uses from other tools.)
>
> When we went to do the intranet side, we thought: let's make  
> intranet "offices" into communities that also get tools.  Most of  
> the stuff is very similar.
>
> Except when it wasn't.  There were lots of exceptions to the rules  
> for intranet vs. community.  And there were some decisions that OSI  
> would make, but others probably wouldn't.  We call both of these  
> "except to the community rules" by the name of "policies" which are  
> implemented in src/osi/osi/views/adapters.py
>
> For example, there is a rule that you don't make anything "private"  
> in the intranet side.  You have to be KarlStaff to see anything in  
> the intranet, and OSI's rule is that KarlStaff can see everything in  
> any intranet office.
>
> Thus, having "Is Private?" on add/edit forms is misleading at best,  
> harmful at worst.
>
> However, these forms are the same views and templates that are used  
> in the community side.  We need a way to flag that, in certain  
> conditions, we want to suppress that field.
>
> I have an adapter (osi.views.adapters.ShowIsPrivate) for this, but:
>
> - It isn't springing into action correctly
>
> - It uses my primitive understanding of adapters.  When I first  
> started doing these policy adapters, I didn't even know I could use  
> __call__ !!  This adapter at least knows that much.  But I should  
> have grabbed them using queryMultiAdapter, so the common case (used  
> inside a community) didn't need an adapter, nor did the tests need  
> to dummy one up.
>
> To Do
> =======
>
> Currently, add/edit folder on the intranet side shows the Is Private  
> field (at http://localhost:6543/offices/files/ and **login as  
> admin**).
>
> Get that fixed, and see if you can clean up other occurrences to use  
> queryMultiAdapter to make life easier for all of us.
>
> I don't know if there are any other occurrences of it beyond  
> folder.  I can't find any.  Once you do Folder, close this issue and  
> we'll re-open as necessary.