sourcefabric-innovation / citizendesk-interface Goto Github PK

An editor can add or delete filters for viewing items from the Twitter stream. These are:

• Twitter user ("follow" in Twitter's glossary)
• Keyword ("track")
• Geolocation ("locations")

Here users will add multiple filter criteria, such as the users @dougiegyro and @BarackObama, as well as the keywords "Mozambique" and "Maputo" and the hashtag #gerais, and location coordinates.

A filter can be deleted, which then stops the stream.

Using standard methods (i.e. Transifex), all strings in Citizen Desk must be localizable.

See sourcefabric-innovation/citizendesk-frontend#37

@msat-cont reported that filter ids in the streams are saved as strings

http://martin.sourcefabric.net/feeds/twt/stream/2

Citizen Desk should allow for single sign-on with Superdesk and/or other services (OAuth, Google, Facebook, Twitter).

Administrators and editors can create a list of blacklisted terms to automatically delete incoming junk SMS messages, or to not send automatic replies.

This blacklist can be edited at any time to better respond to the incoming junk messages.

An editor or verifier is able to write a reply to an incoming SMS. This reply is sent via the core to an SMS gateway (either Kannel, FrontlineSMS, Gammu or other) back to the sender's phone number. The window needs to display the number of characters remaining from the 140 characters.

System privileges are used to determine what a user can and cannot do in the system. There will be a relatively limited set of roles in the system:

• administrator
• editor
• verifier
• citizen

An administrator can attach and remove roles for each user. Users can have multiple roles (i.e. a user can be an administrator, an editor and a verifier).

When an editor decides that an incoming item is worth verifying, they assign it to a verifier.

• The report is visually marked for both the editor and verifier as assigned.
• The proto report tag is nullified
• The verifier can see the report in their incoming queue in real time

Reports can be generated later showing

• which items have been assigned to which verifier
• which items are assigned and are more than 12 hours old

When a verifier logs in to the system, they are led to the incoming queue page. This page lists:

• Items that have been assigned and not verified
• Verification status
• Threaded view
• Option to reply (if reply is implemented)

The verifier also has the option of displaying:

• Further detail about the report
• "Citizen card" including the ability to list previous reports from the sender

extracted from #23

Administrators and editors are able to pre-define automated replies to incoming SMS messages. Examples include:

• "Thank you" message
• Asking for geolocation

A preferences page stores:

• Whether the feature is turned on or off
• Timeout to be set
• The text to be sent in the automated message

The automated message should be written along the lines of:

• "Thanks for your message to @verdade. We will be back with you if we have further questions. Can you also tell us where you are?"

When a user types in a filter criteria (follow, track, locations), the system should return the following:

• Search results (probably limited to a certain number)
• Stream for new items matching the criteria

the pages have to be redesigned, due to:

• absence of grouping
• performance issues preventing direct filtering on the main stream
• requirement to look good on mobile (tablet)

i think that it is better for the new design to be mobile first

The editor or verifier can access a page to create either a blacklist or whitelist of trusted reporters or known abusers. This list can include:

Whitelist

• News organization staff
• Trusted staff of collaborating organizations
• Public figures whose identity has been confirmed

Blacklist

• Known spammers
• Known spreaders of hate messages
• Users sending nonsense messages (airtime, configure, etc.)

Each of these lists should show the average verification score to validate assumptions about the users' trustworthiness.

Listing new items in chronological order in a linear timeline, with newest items on top. A stream returns items from the Twitter API or SMS (or other ingest sources later). Streams will require paging (for older items). Newer items in the thread require real-time updates as they are added to the database.

An editor can enable, disable or delete a filter,

• When a filter is enabled, new items are added to the database.
• When a filter is disabled, new items are not added, but the previous items are stored.
• When a filter is deleted, nothing new is coming in and all matching items are deleted.

@Flowdeeps i linked this repo with my Travis account, but now i am handing over the project, so could you link it to your account please?

When a citizen writes a message (mainly over SMS) that results in a session with multiple SMS messages, the verifier is able to write a summary message that sums up the session and is in the news organization's copywriting style.

The summary message, if used, is the message that is passed to the Live Blog.

Admin users need to set a secure key for communications with remote SMS servers.

In the most generic way

A user logs in with their username and password. This login provides the system with identification of the user, which is then used to determine system privileges.

Currently Sails issues an error when an existing report is modified, for example when some validation steps are checked. The error says:

E11000 duplicate key error index: citizendesk.reports.$id_1  dup key: { : nan.0 }

This may be related to balderdashy/sails#1573

Collects together the various system preferences.

The bigger part of the development of Sails moved to the new branch, 0.10. I think that the branch will probably become the stable one around June or before. Since there are several differences, i think that it is better to use the new version as soon as possible, in order to avoid the need for rewriting and debug again core parts of this code

Realtime update of the reports list is a requirement. Either i will be able to enable this from the backend side, or a corresponding ticket on the front end side should be opened

See also http://stackoverflow.com/questions/23083913/how-to-get-notified-about-external-changes-in-a-mongo-collection-with-sails

Citizen Desk should pass along notifications from its upstream services (such as Twitter) notifying of error messages as:

• Too many tweets, try again later
• Too many criteria
• Invalid ID

and so on. Whatever Twitter communicates to us via the API, we should communicate further to the user.

Items from a communication are presented in a single session, which is then presented to the user in thread view. This means items between a citizen and an editor, or between two or more citizens, would be presented together and in chronological order, so that replies from one to the other can be made visible.

An administrator has to create the user. When the account is created, a password is automatically generated and communicated to the user

On several pages, the editor or verifier needs to select what is displayed in an effective way. Possible selecting parameters include:

• Citizen belongs to a trusted reporters list
• Citizen belongs to a banned list
• Type of report
• Verification score
• More active sessions (lots of reports in the same session)
• Reports from an invididual citizen
• Duplication score (when a report is present in several streams, for example when it is retweeted often)

Filters can be used to select the current display or to affect the visual appearance of reports (for example, to change the color of a report)

The system will securely store information about the citizen reporter. This profile page will include:

• Citizen contact information
• Citizen roles (could also be a verifier)
• Previous messages
• Location
• Verification score (defined at first as plus one for verified report, minus one for report proved false, zero for report not verified)