Design UX interface

[shaunagm]

Need to do some research first - not sure how to approach designing an interface for some of Concord's unusual features - permissions, actions, roles, conditions, etc. Probably want to find someone with more experience to at least review.

Checklist:

• [x] create basic community views (no governance or action stuff) - https://github.com/glizzan/kybern/commit/80816c3252be722069fc9425c46d42c44f8b7491
• [x] add roles interface
• [x] create action include and have it included in community views (now that roles interface lets us generate actions) - this include responding to actions that have conditions on them
• [x] add governance interface
• [x] add "change access to item" interface (for, say, access to a given post)
• [x] add "item history" for actions targeted at a given item (say, a given post)

[shaunagm]

Note: I have some sketches on paper now (on third shelf in home office).

[shaunagm]

Detail: add roles interface

• [x] create basic roles display with not yet working "edit role" and "add people to role" buttons and a "new role" button at the top
• [x] new role: just specifying role name for now https://github.com/glizzan/kybern/commit/6ff0dc58ed8aaf9c000a8b555c51b30c3eec3f14
• [x] make "add people to role" button work
• [x] create modal for adding new members and stick it in the roles section
• [x] update new role: add permissions to the role
• [x] update new role: configure permissions that have been added
• [x] update new role: add conditions to permission https://github.com/glizzan/glizzan-concord/issues/3#issuecomment-599129986
• [x] update new role: configure conditions that have been added
• [x] validate condition data somewhere (concord? kybern django? kybern vue? more than one?)
• [x] add methods to edit existing permissions & conditions
• [x] adapt method to edit member role or create new method for it
• [x] add ability to delete conditions, permissions, people from roles
• [x] the permission_data in a condition needs to work (see https://github.com/glizzan/glizzan-concord/issues/23)

Appearance issues:

• [x] make 'edit role' modal look nicer
• [x] configuration prompts should be nicer than just the field name - maybe the fields need field display names?
• [x] make sure we close modals when it is helpful to close them and not when it is unhelpful to close them (basically click all the buttons and see if the behavior annoys you or not)
• [x] make it easier to swap between html sections (fro
• [x] instead of displaying as 'vote condition' should be the plain english 'on the condition of a passing vote' for examplem condition editing to permission editing, etc)
• [x] make sure state is cleared when switching between roles
• [x] final check for general spacing, colors

Misc issues:

• [x] on backend, roles need to be unique
• [x] on backend, an action which tries to add someone to a role who is already there should fail
• [x] on backend, get rid of singular and only show plurals (don't need [add member] and [add members] - can configure add_members to accept a limit

[shaunagm]

Detail: update new role: add conditions to permission; update new role: configure conditions that have been added

Todos:

• [x] update get_permissions to also get existing conditions in a separate map, with permission.id as key
• [x] then in display of existing permission, do v-if="get_condition(permission_id)" or something similar, returning the condition with key permission.id; should display automatically on opening the modal (though we can't test that quite yet since we haven't finished capability to add condition)
• [x] add_condition, on success, should add the conditions map with permission.id as key, which hopefully auto-updates the 'has permission' section

May have to experiment with making v-if a computed property or something.

[shaunagm]

Detail: "validate condition data somewhere (concord? kybern django? kybern vue? more than one?)"

Okay, so there's two main kinds of validation that can happen here - format validation, and content validation. And so two things need to happen.

• [x] update concord to better check content_data and permission_data for validation issues before it is saved
• [x] provide validation data to the front end so that it can catch things before they're sent

For providing validation data to the front end, this would include:

• [x] specifying booleans and displaying checkboxes to restrict to true/false answers
• [x] with floats, limit range if applicable, and regardless limit to number input (can be done with html5 I'm pretty sure)
• [x] if anything is required, html should require it

[shaunagm]

Running into a problem here, where we're storing permission configuration options by key permission.change_type, but there can be multiple permissions set on a role if we use configuration (for instance, we might have an 'add people to role 'x'' and and 'add people to role 'y') which will have the same change_type (AddPeopleToRole).

Okay, so: permission-configuration-fields is a computed function. We can heck there whether we're update_or_create-ing. If create, do what we've been doing. If update, get the permission id and look up the values in existing_permissions. Then do the same for conditions.

[shaunagm]

This is getting really complex. :/ Is there a way to simplify it?

I could try breaking things out into components, that would at least make things visually easier. Maybe I also ought to take an inventory of the data structures and whether they should be restructured.

And then of course, better documentation via inline comments.

Data structure inventory:

        role_to_edit: '',
        edit_role_error_message: '',
        edit_mode: 'permission',  // Edit mode starts on permission
        update_or_create: 'create',  // Edit mode defaults to creating new permission
        // Data for edit role moda - permissions
        permissions: [], // intitially from server, list of dicts, { id, name, display, change_type, configuration }
        permission_options: [],
        permission_selected: '',
        permission_configuration_map: {},
        permission_to_update: '',
        // Data for edit role modal - conditions,
        conditions: {},  // initially from server, { perm.id : { 'name': X, 'config': { }}}
        condition_options: [],
        permission_to_condition: '',
        condition_selected: '',
        condition_configuration_map: {},
        condition_to_update: '',

        permission_configuration_fields: function () {   (list of dicts)
        condition_configuration_fields: function () { }    (list of dicts)

Okay, so we need our authoritative list of permissions and conditions, with all attendant data, this.permissions and this.conditions.

The permission_configuration_map and condition_configuration_map give us the configuration options, maybe rename to permission_configuration_options? etc

condition_options and permission_options are options for the selects, and condition_selected and permission_selected the choices. permission_to_condition additionally helps us track which permission our condition is to be set on.

permission_to_update and condition_to_update store the database ids for editing.

Which leaves our computed fields, X_configuration_fields, which return a list of dicts; if it is a create, it is taken from configuration_options, if it is an update, it is taken from this.permissions

[shaunagm]

Thoughts on deletions and removals

Need to handle:

• [x] delete permissions from roles
• [x] delete conditions from permissions
• [x] adding people should also allow removing people

Actually none of these require handling dependencies so it should be as straightforward as making sure the call exists on the backend (client, state changes, etc) and then making that call from the front end. Probably order should be:

1. Check if client call exists in Concord and if it doesn't, make it.
2. For deleting conditions and permissions, create a separate button, method on vue, view+url in django. For removing people from members/roles, probably want to add an x on the individual member or an icon of a person with a -, and clicking it removes them from roles/members.

[shaunagm]

Action Includes

• [x] tabular display of all actions within a community (just community, or all owned objects?)
• [x] create interface for approval condition
• [x] create interface for vote condition
• [x] add double-check to get_action_data that makes sure it's on the right target, and gracefully handles it if not

Misc appearance fixes:

• [x] get rid of the default top 5, I don't think it serves a purpose
• [x] move action history button above governance stuff

Okay, so! We should have:

• [x] a little include that says, "Recent Actions" and lists the top five recent actions, with a link to "see action history"
• [x] that link pops up a modal with full action history, aka a table that looks like:

Table:

• [x] has filter which works on all data
• [x] fix created so that it sorts correctly (on actual date, not alphabetic display of date)
• [x] each row has: what the action was in detail; when the action was created; action status; if passed what permission was used to pass it; a field for conditions, possibly with link to condition info

[shaunagm]

More detail on "create interface for approval condition" /"create interface for vote condition"

Condition interfaces are shown by clicking on the "waiting" badge on an open action. (There is a separate non-interactive condition description to describe what happened with a closed conditioned action.) Clicking on the badge pops open a modal which contains the unique condition interface, defined in $conditionname_condition_include.html.

So for instance, in vote_condition_include.html you'd have the interface for displaying the configuration of the condition as well as the buttons "for", "against" or "abstain" (if configured to allow abstention). Clicking those buttons makes an ajax call to process_vote_condition method (currently in kybern/views.py, this is probably among the things moved to Concord eventually). On success, you move to something that shows the current status.

So, steps:

• [x] create a 'waiting' badge in recent_actions and action_history which displays a condition on an action if it exists
• [x] test that setting a conditional on a permission causes an action to be set on a condition and debug if not
• [x] create a approval_condition_include interface for the user
• [x] create a process_approval_condition method on views.py and get it working
• [x] update the front end data upon request (shouldn't need to refresh page to see action history update
• [x] create a vote_condition_include interface for the user
• [x] create process_vote_condition method on views.py and get it working
• [x] handle response back on the front end

[shaunagm]

vote condition interface

if you can vote, and the vote is still open

• Shows basic details of what you're voting on (info from the action details and condition configuration)
• Gives you a button group of yes, no, and optionally abstain, and then "record vote"
• On click of record vote, you send to system. It either gives you an error message, or changes to "your vote has been recorded. Return here to see results when voting ends at X."

if you can't vote, and the vote is still open

Gives details of vote, says you don't have permission to vote. Return here to see results when voting ends at X.

If the vote is closed

Displays details and also the results.

[shaunagm]

okay, the issue is, when saving roles to permission, saving each letter of the role

For now, let's split the x_roles and ex_actors fields by comma, and make a list that way (stripping white space). Soonish, we'll replace this anyway with a multiple select field populated by existing roles.

Validation on this sucks, let's fix the backend too.

TO DO:

• [x] create custom fields on condition template for condition_data and permission_data (once done, should replace the fields in conditionals/utils.py and some of the methods on conditiontemplate model)
• [x] update concord tests to work with the new system
• [x] update kybern to work with the new system, should get an error if it passes a string instead of a list of strings for roles or actors
• [x] once that's fixed, check to see if condition display works

[shaunagm]

Okay, so to refresh the actions, we need to - what? Well, what is the action data structure, and what changes when we respond to a condition?

• [x] for now, we write a get_condition_data method that, given a condition pk, gets data on that condition, including any configured detail or status, and whether the logged in user can take any of the actions. this is called by the condition component, and the ux is shown accordingly - the condition logic is encapsulated within that component.
• [x] when a condition has been updated, we get_condition_data again, and if anything has changed, we update the condition_data in the component. we also check if the condition is now passing, in which case we also get new action data for the action the condition is set on and update it in actions and recent_actions (prob via an emit)
• [x] if an action has changed, we refresh its details by calling get_action_data
• [x] if needed, create second eventbus handler that adds a new action + details by calling get_action_data or some variation on that
• [x] create a new mixin that emits add-action to eventbus and add it to add-role, manage_condition, etc.

[shaunagm]

add governance interface details

• [x] display current governance (owners & governors) in brief text, with a button to edit it
• [x] clicking edit button pops up a modal with governor roles, actors, and conditions; owner roles, actions, and conditions
• [x] implement multiselect for actor and roles fields
• [x] make sure editing owners & governors updates on backend
• [x] make sure editing owners & governors updates on frontend
• [x] adding condition to owner updates on front end and back end
• [x] adding condition to governor updates on front and and back end

Misc stuff that's come up:

• [x] need to refactor the things using vue multiselect, for instance the change membership modal doesn't need to do the current/potential member/display/edit/remove stuff anymore
• [ ] when a conditional action is finally passed, need to update vue (see https://github.com/glizzan/glizzan-concord/issues/25)

[shaunagm]

I am running into formatting issues yet again. The question is, where should the formatting happen? In concord? In kybern/views? In vue?

I want to do some work in kybern because there's key data there, but maybe the point isn't to do the formatting there but just to provide the front end data. So you're not just giving a value from kybern, you're giving all the elements of the field via the api, and it's up to the front end what to do with it? But that doesn't seem great either.

We could format going out but not coming back in...

[shaunagm]

Okay, refactoring to use vuex/stores. Steps here are:

• [x] create toy display to check store is doing data stuff correctly (can also check devtools)
• [x] figure out how to do mutations in the store
• [x] figure out how to do API calls in the store
• [x] refactor, first: adding roles, adding members, editing members in roles
• [x] once that works, refactor existing components to use store for dealing with those three things
• [x] go back and add Store functionality for conditions & permissions
• [x] refactor components to use store for conditions & permissions
• [x] go back and add Store functionality for actions & conditionals
• [x] reactor components to use store for actions & conditionals
• [ ] replace the {{ }} for the initial data with API calls, so that groupdetail doesn't need to override context (or if it does, not for any of this stuff) (see https://github.com/glizzan/glizzan-concord/issues/33)

[shaunagm]

Still to do on permissions & conditions stuff, before moving to fixing actions & conditionals:

• [x] make sure permissions stuff is working (didn't quite finish)
• [x] get conditionals working on edit role
• [x] make sure conditionals still work on leadership include

[shaunagm]

Permissions issues:

• [x] state is being retained in configuration fields :/
• [x] not able to set data in vue multi-select
• [x] update permission displays wonky
• [x] need to implement delete

Multiselect/role issues:

role_name in permissions was saving as list, needed to implement a few things here:

• added other_data to configurable field so we can pass logic that the role_name in addpermissiontorole state change is a single select, then added logic in kybern to look for it and format accordingly

• better validation of new permissions, added fairly extensive validation in addpermissionstatechange's validate method in concord

[shaunagm]

When creating permissions via editing roles, we're not checking for existing relevant permissions. So if I give the permission AddPeopleToRole to Role A and Role B, it creates two separate, conflicting permissions, rather than saying "oh an AddPeopleToRole permission already exists on this target, let's update it".

Permissions.py handles this on the backend - it will check multiple permissions - but it looks pretty weird on the front end.

To fix this, we could create an update_or_add_permission method on client that checks and updates if it finds something, or creates a new permission if it doesn't. The downside of this is that AddPermission and AddRoleToPermission (or AddActorToPermission, for that matter) are two different permissions and so there may be some confusion there. But this is probably best for now.

[shaunagm]

More detail for "change access to item"

For any permissioned item, we should display to the user a little pencil icon (or, eventually, a 'permissions' icon). Clicking the icon should pop up an interface for editing the permissions (and conditions) associated with the object.

This should be fairly similar, UX-wise, to "edit role", except that instead of already knowing the role and the target (the target in edit role being the group as a whole), we only know the target (the permissioned item). So we'll need the additional interface showing potential roles & actors (like we see in the leadership include) plus the normal interface. But we should be able to keep the same vuex data structure.

Notes: when we create the "edit forum" permission via a specific forum it should be a permission configured to only be for that forum, at least when the target is the community? GAH, I need to better figure out nested permissions, pressing pause here

[shaunagm]

Item history details

Should be a button of some kind on an item (forum, post, anything permissioned) that, when you click it, pops open an action history similar to (same as?) the group history but with actions targeted at that item.

We don't want to preload the action history for everything all at once, so on clicking the button we'll need to make a call to the server to get the action data for that item, and store it in vuex.

• [x] update vuex to handle actions on multiple objects
• [x] create actions on vuex with corresponding server views/urls to get actions and update the data store
• [x] make sure get_action_data adds action to the appropriate place in vuex
• [x] create component/include to actually view/interact with this data