Merge edit_acl_view into advanced

[Paul Everitt]

In KARL2, OSI used the Plone UI to let admins set local roles. Even if we use a rudimentary UI, this is much better than our plan to do it in bin/debug.

Tres wrote a view:

  <!-- Publish static resources under /static/ -->
  <view
    for="*"
    view=".acl.edit_acl_view"
    name="edit_acl.html"
    permission="administer"
  />

...which, though currently broken (TypeError in render) is advertised to do what we need. We just need to merge it into the UI.

We have an action "Advanced" which appears in the menu on folder-ish content for KarlAdmin users. This would be a good place to migrate this functionality from the view above, into the advanced_folder_view.

Spec
========

1) Get the edit_acl_view working again.

2) Make a second section in the advanced_folder_view. Perhaps use H4 heading to segregate sections. Don't invest too much in usability, this is for admins.

3) Merge the logic and UI from edit_acl_view, into this new section. Use different form submit button names to allow the different forms to be processed. (Or, find some other solution.)

4) Remove ZCML, view, and tests for the edit_acl_view.

5) Make sure the tests for advanced_folder_view test the existing (Assign Markers) and new (Edit Security) sections. Probably need some work on this.

6) Ensure that the Advanced action shows up in the green actions menu for the correct screens. I suspect it should appear in just about everything: community, offices, office, folder. I doubt it makes sense on the tool folders themselves.

Bonus points:

1) Consider list of known markers. Right now, the list is completely arbitrary. Perhaps leverage taggedValues and allow an interface to declare itself as a Content Marker or something.

2) Re-think the way we do the actions box. It screams out for some kind of abstraction. Perhaps lemonade:listitem or something like that. I wouldn't mind registering the action itself in one place, then referring to it in each view. If you choose to go this route, let's make a new task and writeup everything we know about it (e.g. we have a UI need to distinguish add actions from other actions.)

[Shane Hathaway (shane-hathawaymix)]

I have done step 1.

Steps 2 through 5 of the spec seem to say I should make the edit_acl.html view specific to folder objects and not usable elsewhere, then step 6 says I should make the view usable practically everywhere. I'm confused.

I could only do steps 2-5 and ignore the rest. That would be fast and easy. Or I could ignore steps 2-5, create an abstraction for action buttons as described by bonus point #2, register the ACL management view as an action in a category called "advanced", and show all advanced actions in one page when the user clicks the advanced button. This is more work, but no more than a couple of days.

Which should I do?

[Paul Everitt (paul-agendaless)]

Trying to get this into "Advanced" and getting the generic_layout on it isn't mandatory, so I'll mark this as closed. Particularly since this is just a temporary UI.

For now, it will mean admins will just have to "know" the URL to tack onto a folder to get to this screen.

[Paul Everitt (paul-agendaless)]

Move to M15.

[Paul Everitt (paul-agendaless)]

Oops, this got done.