net-ng/kansha

Manage and share collaborative pinboards on the web.

KANSHA

Kansha is an open source web application to manage and share collaborative scrum boards and more.

Kansha works with Firefox, Chrome, Internet Explorer 9 and above, Safari 7 and above.

Quickstart

Latest stable release is version 2.0.0

Try Kansha online or install it on a computer:

• Run the latest stable release with Docker:

  docker run -p 8080:8080 netng/kansha:v2.0.0
  

• Install and run a stable release from Pypi: see the installation documentation

• Or run from the latest source: see the developper documentation

Issues

If you have any problems with or questions about Kansha, please contact us through a GitHub issue.

Contribute

Join us!

• Github: https://github.com/Net-ng/kansha
• Bitbucket: https://bitbucket.org/net-ng/kansha
• Mailing list: http://groups.google.com/group/kansha-users

kansha's Issues

Display chips labels on card form

On the card form, displays card labels and color...

...and not only their color :

Archive all the cards from a list

From a board, you can archive all the cards in a list. The list is maintained.

Hard coded paths in error pages

The app name is configurable so don't hard code urls in files. Concerned: error page templates.

Board description and special character escaping

When i put "\n" as description of my board, after i can't change it again.

Configurable themes

We want configurable themes for kansha, to make it easier to customize, and get rid of custom_css.

A theme is a set of CSS files put into a subfolder of static/css/themes.
Since #79, we already have a theme static/css/themes/kansha_flat

• Instead of hardcoding it in views, make it configurable (only the last part — e.g. kansha_flat — in the application section of the configuration file).
• Remove custom_css everywhere.
• Update documentation:
  • Configuration file: replace custom_css by theme and explain.
  • Developer guide: explain how to add a theme.

Smartphone view - Reduce tab size and input length

All tabs should be on the same line here :

And input length :

Moving items in lists

On each card, you can move the items in one list by drag and drop, and be able to move items between lists :

Import and export boards

Use case

As a board manager, a user can export the contents of its board and save it as a template.

On a board view in the board menu, an option "Save as template" is available. Clicking on it will open an overlay on which the user can:

• Enter a title for the template
• Enter a description
• Select if the template is available for all users or the user only

Validating the form will trigger a "Wait animation" and a confirmation message will appear.

On the homepage (boards list), replace the "Create a board" input with a list of existing templates ordered by title.

Choosing one will create a new board and redirect the user on it.

Export content

Exported data is marked with ✅

Board

• ✅ Title
• ✅ Description
• URI
• ✅ Background image
• ✅ Background image position
• ✅ Title color
• ✅ Comments allowed
• ✅ Votes allowed
• Visibility (private or public)
• Show archive column
• ✅ Weights activated
• ✅ Weights list
• ✅ Columns
• ✅ Labels

Label

• ✅ Title
• ✅ Color

Column

• ✅ Title
• ✅ Max cards
• ✅ Cards

Card

• ✅ Title
• ✅ Description
• Votes
• ✅ Labels
• Comments
• ✅ Assets
• ✅ Checklists
• ✅ Cover image
• Due date
• ✅ Weight

Comment

• Comment

Checklist

• ✅ Title
• ✅ Items

Checklist item

• ✅ Title
• Done

Implementation

• Add a flag on DataBoard to filter templates from boards
• Assets are copied through AssetManager

Cards do not open properly

When the board is very large, a horizontal scrollbar appear. But when we scroll on the right then click on a card from a column far on the right, the popin does not show properly:

• the background mask does not extend to the right of the screen
• the popin content window is not visible

Indicators on several lines.

On a card, all indicators should be displayed by default on a line.

Centralize History feature at board level

Objective

History recording is currently spread across almost all the significant components (board, column, card, checklist, comment and gallery). This is a bad design in the perspective of making History a pluggable feature.

The objective of this first step is to centralize all History operations in the board component.

Implementation

All components below a board will "bubble" their important actions through calls to answer(event) where event is a tuple (action, source, data):

• action: (str) an action code;
• source is a list of business objects, each component relaying the event up must append itself to it; (asking the community: is using a list here safe? should we use a tuple instead?)
• data is data specific to the action.

In general, when a component receives an event from its children that it is not able to handle itself, it must answer() it up, appending itself to the source by the way.

The board will then record all these actions in the history.

Sign in - Error message

Design bug :

We should have :

Separate Core API from Features on DataCard

All changes have consequences in other parts of the code that must be updated.

Properties

Core properties:

• title
• index
• author?
• creation_date
• uid as uuid to replace adhoc 'card_XX' id?

Property to remove:

* column; only column shoud have a handle on cards. needed for some joins

All other properties are considered belonging to features (including members). Group them and comment accordingly.

Methods

create_card and delete_card belong to DataColumn, as instance methods.

Rename remove_board_member to remove_member.

All other methods are considered belonging to features. Group them and comment accordingly.

Slogan is wrong

The password confirmation page, the slogan under the logo is not good :

'<' character in comments

When I use '<' in a comment, some content is silently removed.
This can be annoying, for example:

Usage: my_prog <mandatory_argument> [optional_argument]
turns into
Usage: my_prog [optional_argument]

Activate feature when age < 18 and user is not the captain
turns into
Activate feature when age

Smartphone views - Design flaw

The search magnifying glass should not be displayed :

Different icon should be used to display "export board" action :

The "SIGN IN" and "SIGN IN WITH LDAP" buttons must have the same design, even in smartphone view. The good ones :

and

Link to the card

Provide on each card an HTTP link to the card (to the edit popin of the card).

On the editing form of a card, add a button "Share it" opening a popin displaying the URL shortener to this card (eg https://demo.kansha.org/d/lkrJf7JdT).

Card label - Synchronization error

When my card label contain only spaces, i have "Synchronization error" when i save.

Calendar view mode

On calendar view mode, when you drag and drop a card onto a new date, the new date is not saved when you go back on standard view mode.

Make Kansha install cleanly with pip

Pip is now the preferred tool for installing python packages. It supports semantic versioning and wheels, uninstalling, and many more features than the old easy_install.

Reorganise files so than Kansha supports flat installation and does not expect to be installed in egg format.

Confirmation message before deleting a list

Ask for confirmation before deleting a list :

Define Core APIs and properties of Card BO and dependencies.

Depends on #94, #96.

Core API

We distinguish to kinds of core API:

• business methods (a.k.a. Component API)
• internal methods

Internal methods are used by the component only. In particular, methods and callbacks for the views are found here.

Business methods and properties

• set_title
• get_title (or property)
• delete: prepare component to be deleted. It's up to the column BO to actually delete it, and to the column Data Model to destroy the DataCard.

Internal methods and properties

• uid: to get the card uuid (prop)?
• data: to get DataCard
• reload: to initialise all feature components. See #96.

View specific

Methods to move elsewhere

• move_card: only Boards can do that.

Methods and properties to remove

• column: remove from card API. If you need to communicate with parent, use comp.answer to send an event. Maybe still needed in features API.
• must_reload_search, reload_search: send an event instead. See #85, bubbling events.
• board: if you need to communicate with ancestor, send an event.

Features API

To be grouped apart, with comments. These functions will be moved to extensions when those have their own data models.

• favorites: remove direct access to Column, use comp.answer to send an event.
• weight
• get_authorized_users: remove direct access to Column, use comp.answer to send an event.
• get_authorized_users
• get_available_labels: remove direct access to Column, use comp.answer to send an event.
• *_member* methods: remove direct access to history/column, use comp.answer to send an event.
• methods added during #96.

Distinguish the boards on which I am invited, my boards, and boards recently consulted

On my home page classify boards in this order:

"Last modified boards"

 board 1
 ...
 board 5

"My boards"

 board 5
 6 board
 ...
 board 1

"Guests boards"

 board 1
 board 2
 ...

For last modified boards, display only the 5 most recently modified boards I have access to.

[edited by @rtxm on 2015-10-30]

Delete a list

When you delete a list with cards, those cards deseappear and are not moved in the archived list

Filtering cards on user

In the search input, if we enter "@ ept" then the search engine displays all cards where that member has been added (cards, comments).

Wrong "Position" items number.

From a board, when I enable or disable the "Archive" column, the combo "Position" of the popin "Add list" always offers the same number of positions even after adding more. If i go back to Kansha home page, and i return to this board, this combo works again.

Don't do in JS what can be done in CSS

Many effects can be achieved in CSS rather than in JS, with better efficiency.

• The kansha and board menus should be displayed on hover in pure CSS
• Most tootips are useless: remove them or reword them
• Tooltips should be displayed in pure CSS

Search engine - "Archived cards" list

Exclude archived cards from search unless the archive list is displayed.

Error when there's HTML markup in a comment

When I add HTML markup in a comment (such as <li>), an error occur when I try to save it.

Confirm message and due date

Display a confirm message before deleting a list.

When a card already has a due date displayed...

...we should change it directly when we click on it.

Change the link "Add a card"

On each list of a board, add a link "Add a card" after the last card. Hide the actual button "Add a card". The action is still the same.
Always keep this link on the screen, even if the number of cards exceeds the screen.

Is bootstrap really necessary?

It looks like we hardly use bootstrap at all, or just to reset the styles. In that case, why not use the lighter knacss used on the login page and get rid of boostrap to speed up page loading a bit?

Page truncated on my tablet

Several lines are hidden under the footer, "You are running....each." :

Board title

Prevent from empty title and title with spaces.

Save a board as a template

Expected behavior

If a custom template directory is configured, we allow users to save the current board as a template. The template becomes available to all users.

On a board, in the board menu, a new entry is available for board owners: Save as template.
When a user clicks on that entry, a pop-up appears asking whether the template is personnal or public.
The new template appears in the list to create boards from on the user's home and, if public, on all users'.

Technical notes

Use a kind of delegation pattern: each level (board, column, card) is responsible for exporting its own JSON fragment.

Use AssetManager to store templates.
Create a new relation in DB between user, board, template asset UUID and a boolean (shared indicator).

Boards order

From my home page, you can change the display order of my boards or boards on which I am invited.

French translation missing or wrong

Missing here :

And wrong here :

Should be "Autoriser les votes"

Centralize card indexing at board level

See #85.

Card component : handle features in a generic manner.

Apart the title, all the features of cards are to be treated as extensions.

The features are already implemented as separate components, but each one is handled explicitely. We want to handle them "anonymously", all the same, from the Card point of view.

Impact

Card Business Object Component and Internal APIs

• reload: to initialise all feature components. All features are already in distinct classes. Handle them "anonymously", that is, all properties self.comments, self.descriptions are replaced by a list self.extensions. Extensions are instanciated in a generic way too, from a list of Classes (for now), with self passed as parameter, and services (call services_service).
  You may need to adapt existing extension classes to unify the way they are instanciated.
• delete: call a delete method on each extension
• favorites: should become a Component API returning user business objects for a new Favorite component of the "Members" extension.
• If feature components try to access to properties or methods under Card.data, add a new component API to Card and use that instead.
• Comment and group methods and properties of Card that are specific to features (e.g make_cover, ...)

Card Views

The card views should now handle extensions in a generic way too. To make things simpler, each Feature Component must provide those views (possibly empty):

• 'header', for the compact view (inside board), in card header;
• 'cover', for the compact view, in card body;
• 'badge', for the compact view, icons in card footer;
• 'action' for the action menu of card edit view;
• and a default view (for full card display/body of edit view)

There should be only two card views after that: default and edit.

Feature Components

Feature components are to be adapted to work nicely in the new approach. Create a base class providing the default views for the models ('header', 'cover', …) and common API.

• If feature components try to access to properties or methods under Card.data, add a new component API to Card and use that instead.

Can't delete file of my card.

On my card i can't delete a file/image if I already have clicked on its "Make cover" link. I must close and open the card form again to access the Delete action.

Define core APIs and views for cards

Objective

Prepare card model and component for when we'll extract features as discoverable extension components.

Steps and guidelines

See #94, #96, #98 for detailled issues.

Card model (aka DataCard)

• Distinguish, in the code, properties essential to a card from properties belonging to features
• A card model shouldn't know anything about its parents or feature extensions
  • Remove any reference to parents
  • Move any method using a reference to a parent higher in the hierarchy
  • Distinguish methods essential to the card from methods belonging to features
• If a method uses more than data accessible from self, or settable to self, move it to the associated component

Of course, if you move methods, fix all callers.

Card component

The card component manages a card model and its features. It provide an API to card views and parent components. It knows nothing about persistence, has no reference to its parents, and preferably doesn't fiddle with subcomponents of its children.

• Remove any reference to parents. If the component needs to communicate with its parents, use answer() and/or return values from API called by a parent. If it needs info from its parent, use method calls/callbacks or parameters on its contructor, or return value of comp.answer().
• Distinguish, in the code, methods and properties essential to card management from those belonging to features.
• Move any database querying to the card model.
• Try to handle components for features "anonymously", that is, in a generic way (see also view).

Card view

• Separate the core views of a card from the rendering of features
• Since we are now handling features as "anonymous" components, we should approach their views in a generic way. For each feature, define and handle views 'header', 'cover', 'badge', 'action' and a default view (for full card display).

"Archive" column not refreshed after having purged cards

When i try to purge my "Archive" column, cards are still there. I must refresh my page to make them disappear

Bad footer position

On the login screen, the footer should stick to the bottom of the page when resizing the browser window. See screenshot.

Always in English when i connect with a connector

When I log on Kansha from Google connector or another, the Home is always in English and as soon as I click on "Profile" or my "Welcome board", it switches to the language selected in my profile here in French.

Wrong translation : "Must be be bigger than..."

When i try to change the number of limited cards on a list, the error message is wrong :

Formatting card description

Rich text editor for card description : bold, italic, underline, bulleted list, numbered list and insert http link

Responsive design to change

The responsive design for Kansha home page must be reviewed. With a page in addition to 1300px wide content already fail over a single column.

Create board from a template

Actual state

If a template directory is configured, all template files present in it are automatically loaded and boards created upon user creation (actually, at first login).

When a user creates a new board, a hard-coded template is used: three lists Todo, Doing, Done.

New expected behavior

Don't automatically create boards from templates upon first login. Instead, let the user create boards from the availble templates, as detailed below. No more hard-coded templates.

On their homepage, users can create new boards. In order to do so, a drop-down menu of all available templates let them chose the template they wish to start from. No more text input, the title of the board can be modified later, on the board itself.

In the dropdown menu, templates are identified by their titles, not their filenames.

When the user clicks the Create button near the dropdown, a new board is created from the selected template, and the user is redirected to the new board.

Provide some default templates into the distribution (at least, the Todo, Doing, Done template). The shipped templates are always prepended to the list of templates found in the configured template directory.

Technical notes

Use a kind of delegation pattern: each level (board, column, card) is responsible for configuring itself for its own JSON fragment.

• Board configures itself and create columns, passing to each column its JSON fragment ;
• Column configures itself and create cards, passing to each column its JSON fragment ;
• …

Simplify styles

Objective

We aim at a clean, minimal set of CSS files for Kansha and a clean, flat and consistent style throughout the application.

User experience

• Reduce the number of colors. For example, we don't need so many levels of gray
• Make the design flat (the simpler, the better):
  • get rid of gradients
  • don't put shadows inside inputs or text areas
  • remove shadows around elements that are not active
  • replace sprites and icons by fonts
  • don't emboss emblems when hovering over cards
  • remove useless crosses in pop-ups
  • remove double-borders

CSS organisation and guidelines

• General: http://kansha.readthedocs.org/en/stable/contribute.html#fix-bugs-and-code-new-features In particular simplify and avoid over-qualification (at most 2 levels if possible, never more than 3)
• Distinguish structural CSS (element layout, responsiveness) from "cosmetic" CSS (put them in different files)
• Put CSS specific to each environment (home, board, login…) in a different set of (structural, cosmetic) files. Put common CSS in its own set:
  • at the folder static/css/themes:
    • Common structural/functional CSS kansha.css and font definitions fonts.css
    • Structural CSS for each environment login.css, board.css, home.css
  • in a subfolder static/css/themes/kansha_flat:
    • Common styles in kansha.css
    • Styles for each environment login.css, board.css, home.css
  • at the root of static/css, it should only remain bootstrap, knacss and ckeditor.
• Update the views to include the appropriate files in the right order (struct common, struct env, styles common, styles env)
• Concerning the CSS for boards, lists and cards, make sections in your CSS files to easily find each object's styles. Make subsections to separate core CSS (e.g the card/list/board itself) from the CSS of features (e.g. tags on cards, search on boards, covers, comments…)

Viewing and Hiding week numbers

We would like to display or hide week numbers on the calendar view 👍

and also on the input interface of a deadline :

Take care : in the USA, the week number changes every Sunday and the rest of the world it changes every Monday.