Suppress Is Private in intranets

Bug #360555 reported by Paul Everitt on 2009-04-13
2
Affects Status Importance Assigned to Milestone
KARL3
Medium
Shane Hathaway

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.

Changed in karl3:
assignee: nobody → paul-agendaless
importance: Undecided → Medium
milestone: none → m10
Paul Everitt (paul-agendaless) wrote :

Intranet stuff is lower.

Changed in karl3:
importance: Medium → Low
description: updated
Changed in karl3:
assignee: paul-agendaless → shane-hathawaymix

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
Download full text (3.2 KiB)

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 fin...

Read more...

Paul Everitt (paul-agendaless) wrote :

Rolling over to M11.

Changed in karl3:
milestone: m10 → m11
Paul Everitt (paul-agendaless) wrote :

Re-jiggering the priorities.

Changed in karl3:
importance: Low → Medium
Tres Seaver (tseaver) wrote :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Everitt wrote:
> 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.

There *isn't* any workflow desired for those objects (inside the
intranet). I think I saw you check in a fix which made the
AttributeErrors go away, which should be fine for the intranet.

A better fix might be to move the workflow-centric UI elements into the
"layout" somehow, so that the check wouldn't even be done when in the
intranets.

>> 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.

Annotations feel like over-engineering to me.

Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 <email address hidden>
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJ7JDx+gerLs4ltQ4RAo00AKCwfawEiCHfJP2DkUtVMedr++zM2ACfdG2K
gzqPD6ffftL9RgJoqJTLk1M=
=3Fp3
-----END PGP SIGNATURE-----

Tres Seaver wrote:
> There *isn't* any workflow desired for those objects (inside the
> intranet). I think I saw you check in a fix which made the
> AttributeErrors go away, which should be fine for the intranet.
>
> A better fix might be to move the workflow-centric UI elements into the
> "layout" somehow, so that the check wouldn't even be done when in the
> intranets.

Ok, I'll look into this.

> Annotations feel like over-engineering to me.

Quite possibly.

Shane

Paul Everitt (paul-agendaless) wrote :

On Apr 20, 2009, at 11:12 AM, Tres Seaver wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Paul Everitt wrote:
>> 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.
>
> There *isn't* any workflow desired for those objects (inside the
> intranet). I think I saw you check in a fix which made the
> AttributeErrors go away, which should be fine for the intranet.
>
> A better fix might be to move the workflow-centric UI elements into
> the
> "layout" somehow, so that the check wouldn't even be done when in the
> intranets.
>
>>> 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.
>
> Annotations feel like over-engineering to me.

Speaking of over-engineering, the way I did the LayoutProvider would
provide the thing you mention above. The idea was that some layouts
needed some content and it wasn't right to have the view assemble
every o-wrap value that might be needed. In fact, the view might not
know what layouts were installed and what they needed.

Chris had an aversion to using TemplateAPI as a garbage barge. I made
LayoutProvider into, we'll say, a garbage dinghy. Each flavor of
layout adapter returns something that has a namespace where it can
stash data used during rendering.

--Paul

Fixed in revision 2263.

Changed in karl3:
status: In Progress → Fix Committed

I decided that the root of the problem is the use of the wrong workflow within intranets, so I created a no-op workflow for intranet content. I also made the ShowIsPrivate adapter check for an IIntranets context.

I should also work out how to simplify the "is private" logic.

Changed in karl3:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers