Define Core APIs and properties of Card BO and dependencies.

[rtxm]

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 Card component : handle features in a generic manner. #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 Centralize History feature at board level #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 Card component : handle features in a generic manner. #96.

[rtxm]

I take it.

[rtxm]

Fixed in #138, #126