It will be nice to provide a translated interface.

BUT: apps which is what people see will be largely in one language - so how useful is this ...

In order to clean a bit more the base.html file, create a partial for the navbar.

Theres is a typo in the name of the application, so the I don't know button does not work anymore.

Implement an authentication method for API usage. As the The Facto pattern for this, OAuth should be considered a first candidate. The following blog post appear to show the path: http://philipsoutham.com/post/2172924723/two-legged-oauth-in-python

This follows on from discussion in #10. Issue is how we mount TaskPresenter for a given app into PyBossa

NB: it is also possible that the TaskPresenter lives completely outside PyBossa but that is more complex (and for that a) need to enable CORS b) work out how user identity works.

Proposal

• Each app info object has a key named: task_presenter. The value of this is a hash is html and javascript representing for the TaskPresenter. PyBossa will inject this material directly into the page.
  • Note this HTML can also rely on some JS info also being in the page which it can use, namely:
    • var PyBossa.currentUser - an object representing the currentUser including at least an id attribute.
    • var PyBossa.currentTask - an object representing the current task.
  • callback_url: a url which will then be iframed into the task page
    • Question: how is data (e.g. task info) passed to the TaskPresenter. Remember iframes can't access anything from their parent.
      • Answer: we json serialize the Task object and inject it into the page hash in some way or other (or just put it into the query string?)

Background

@nigini: https://github.com/citizen-cyberscience-centre/pybossa/issues/10#issuecomment-3181462:

Have you seen the Facebook model? when you register an App, you have to put a "callback" url, so, when a user (at pyBossa) calls for the application, we provides a frame with the given HTML!

Could try using ep.io?

Location: /app

Show nice list of apps (classic styled ul ...)

For each app show:

• name (link through to app page - see #17
• shortened description (first 100 words?)
• image
• create date and last active

Do not show hidden apps ...

• Need not be connected up to db (and do not require signup or login)

Changes:

• Add StateEnum
• Add relationships in SQLAlchemy (e.g. tasks attribute on App and app attribute on Task)
• Add some fields as detailed below
  • Add owner to App
  • Add quorum field (int) on Task
  • Add an api_key, fullname field to user
• Change create_time to be a date time (iso8601 string) -- ditto for finish_time (also rename to created?)
• Rename job to task
• Drop Batch object

Use SQLAlchemy-migrate to allow migrations between different DB upgrades.

The demo application will grab a fixed number of photos from Flickr with the meta-tag: "rainforest" . The application will show the photo to the users and ask the following question: Do you see any deforestation? The available answers will be: yes, no, I don't know.

• Set mime-type to application/json for API JSON stuff.

Want a page for each app. Could show stats for that app e.g. how many tasks there are and how many have been completed.

Location: /app/{short_name}

Show:

• name
• description
• image
• task count
• create time
• last task done datetime

Create /sql folder and put in bossa sql as e.g. bossa.sql

For the moment the DB is covered by the Open Database License, but we should also cover the code. For me the best solution for this software should be the GNU Affero GPL v3, as it will be possible to create a service or platform based on this code.

What do you think @rgrp ?

following emails, work in Berlin and in Campina Grande and agregating all the information here:

taks: create a Table-Transcription platoform for extracting data from tables in scanned pages. This would be a general platform, but one use that interest me is to extract historical data on demography, heath and crime in XIX Brazil.

The idea: half the page with an image and half the page with a some sort of spreadsheet where the data is transcribed by the volunteer. There may be intermediate steps before the table appears in which the volunteer identifies if there is a table in the image and fill in some metadata about the table (title, stating and ending page (in case of tables spanning more than one page, type of data, source).

Other infos:

1)Campina Grande folks (@nigini and Jey) already developed a platform. Details:
-Task management is done using the original Bossa (PHP)

• The table is done by a jQuery Spreadsheet plugin (http://www.visop-dev.com/Project+jQuery.sheet) (@nigini: "Basically, we get the text inside spreadsheet cells, convert it to JSON and store at the "TaskRun" instance. When another task for the same page will start, we recover the data from the last TaskRun and push it back at the spreadsheet. In this way we have a Wiki alike collaboration, and the systems maintains all data versions"(.
  You can test it by:
• create acount at: http://bacalhau.lsd.ufcg.edu.br/table_transcriber/create_account_form.php?next_url=home.php
• login and start transcribing at: bacalhau.lsd.ufcg.edu.br/table_transcriber/bossa_apps.php
• the code behind that application is at: http://svn.lsd.ufcg.edu.br/repos/sc/table_transcriber > user: "anonymous" , leave password blank.
• the project documentation is maitained here: http://redmine.lsd.ufcg.edu.br/projects/datadigitizer (but it is out of date and the server may be down).

2. We need to think what is the best table-spread sheet solution for this. Options that I know of:

• jQuery Spreadsheet . The advantage is that is all runs in our server. But it may be dificult to ajust stuff and less intuitive to the user.
• googleDcos spreadsheet. We can use "googleDocs API 3.0" (pytho) to manipulate table creation, user access, etc. And "googleSpreadsheet API" to manipulate how the page is embeded and etc. Disadvantage: other server, relies on google. Advantage: more powerfull, more intuitive.

@rufus, @nigini, @teleyinex : do you know any othe options? In your opinion, what is the best option?

The topbar does not update its state based on the active URL.

@rgrp should we update to 2.0.0?

It will be interesting to register how much time a user spends in each task, as well as in different applications, the web site, etc. This information could be very useful for the owner of the application, as it will be possible to analyze with more details which tasks were more complicated based on the time, and it will give the option to the project to create user rankings based on real time collaboration (not only how many tasks have been completed).

As usual any comments on this issue are welcome.

Suggestions welcome.

Some ideas:

• MicroTasker

It is important to discuss the minimum requirements that PyBossa will have according to authentication and authorization.

NB: Authentication in WUI already works and API key autentication is #20.

Authentication: for the moment there is a basic authentication method, that allows users to create an account, sign in and sign out.

Authorization: it is mandatory to identify which actions will be valid for different types of users. For the moment I think that the following roles will be possible:

• Project managers: these users will be able to administer all the registered applications within the service. Thus, they will be able to create, update and delete applications, as well as all their associated data.
• Users: these type will be allowed to participate in different applications registered in the system, as well as creating their own applications thanks to the UUID API key which is generated when you register an account. For these reasons, these users will be able to: create, update and delete their own applications as well as the associated data (tasks of the applications created by the user).
• Visitors: it could be interesting to allow visitors contributions to different applications. Thus, there should be an option within the creation of the applications to allow visitors contributions. Visitors contributions could be very valuable as it will help new users to try the system and get involved without all the problems of registering, at first, a new account. These type of accounts will allow to play directly and contribute as in Wikipedia or GalaxyZoo.

@nigini, @rgrp it will be interesting to have your comments and feedback about these items.

Additional proposal (from RP -- but please mod)

NB: I think it would also be useful to have listed relevant user stories (or, at least, situations). That would help us check we have covered edge cases.

Situations - CRUD on core domain objects

App

• Create: User creates an App (Visitor cannot create app). User becomes owner of app
• User updates an App (user must be owner of App)
• User deletes an App (ditto)
• Anyone can view an App unless it is hidden (in which case only owner can view)
  • Listing is same as viewing except we hide hidden from everyone including owner (to avoid special-casing)

Task

Tasks are always related to an App.

• Create: Only App owner can create Tasks for their app
  • TBD: could an application have collaborators to submit tasks?
• Read: anyone can access
• Update: only app owner
  • TBD: collaborators?
• Delete: only app owner
  • TBD: collaborators?

TaskRun

• Create: Only logged-in users can create TaskRuns
  • RP: Should we have a special flag on tasks that indicates it can be run by anyone including non-logged in? Seems useful to allow some visitors contribution.
    • DLG: Yes, I think that a flag will be enough, so app owners can see which tasks have been submitted by visitors or registered users. +1 to this!
• Read:
  • The owner can read all the TaskRuns from his application.
  • The User can read all his created TaskRuns.
  • RP: why not allow everyone to read task runs - it allows them to build stats apps of their own
    • DLG: apparently it could influence other people answers, but we can discuss this at a later stage. Thus, I agree with you for this point. +1 to this.
• Update: all registered Users can update their TaskRuns (i.e. fixing errors)
  • Visitors task runs cannot be updated.
• Delete: all registered Users can delete their TaskRuns

Implementation

See these two (almost identical implementations):

• https://github.com/okfn/openspending/tree/master/openspending/auth
• https://github.com/pudo/datahub/tree/master/datahub/auth

Even simpler option:

• https://github.com/okfn/webstore/blob/master/webstore/security.py

Write an Announce Post. Then can send around.

• What
• Why
• Who and When
• Screenshots
• Link to Demo
• Link to docs

• Suggest creating tutorial-simple-app.rst in the docs with basic info. Focus should be on Task Presenter since other parts should be covered in main docs.
  • Creating App -- suggest this go in main docs rather than this specific tutorial. Present approach will be via the API at the moment -- but soon will be in WUI - see #22
  • Covers creating Task Presenter (most important!)
  • Covers creating Tasks (via API) -- as for Creating App feel this should be in main user docs rather than this tutorial
• Tutorial can build on demo in #10 (i.e. that could be the tutorial).

There should be a blueprint for the applications, as for the accounts. This will simplify the development.

dictize and undictize should convert to / from a dictionary suitable for JSON serialization.

Should move here from API section as should be specific to domain object

Use http://packages.python.org/Flask-Gravatar/

May want a simple helper method for showing a user link (which includes link to user page + gravatar).

Some of the CRUD methods are triggering some critical errors due to there is no view at all to show when for example an application does not exist. Thus, it will be great to include the exceptions and related HTTP codes for the developers.

Should have a nice list of accounts at account home (/account) rather than just a blank page.

We could mock up now (even though we don't have the data info) things like number of tasks done by each user.

• Add version of PyBossa in Powered by section in footer
• App section in top menu with drop down for list of applications a la http://openspending.org/

Location: /{api}/app/{id}/newtask/[{user-id}]

user-id is optional (may not be logged in!)

Provide basic sphinx docs covering at least the API (API docs are essential to building demo app in #10)

• Boot sphinx skeleton docs
• Key concepts and Domain model
• API docs

Extra bonus points for deploying the docs somewhere public

Would be especially nice if this grabbed stuff from a csv file or url (then we could autoload from e.g. google docs ...)

See also: #10 (demo application)

Schema for CSV

Columns:

• app_id (or app short_name?)
• all other columns go into info dict of a Task. Can use 'dotted' notation in column titles e.g. x.y would mean we had entry in info dict of { x: { y: value} }

In the way the API is today, the client needs to know the Task ID to call for a task to be presented to the user. But in a system like PyBossa, the server should decide which task should be delivered (and maybe there are different algorithms to be used) each time a client asks for a job.

ERROR:pybossa.core:Exception on /account/register [POST]
Traceback (most recent call last):
File "/opt/pybossa-env/local/lib/python2.7/site-packages/flask/app.py", line 1504, in wsgi_app
response = self.full_dispatch_request()
File "/opt/pybossa-env/local/lib/python2.7/site-packages/flask/app.py", line 1264, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/opt/pybossa-env/local/lib/python2.7/site-packages/flask/app.py", line 1262, in full_dispatch_request
rv = self.dispatch_request()
File "/opt/pybossa-env/local/lib/python2.7/site-packages/flask/app.py", line 1248, in dispatch_request
return self.view_functionsrule.endpoint
File "/mnt/work/Workspace/PHD/PYBOSSA/pybossa/pybossa/view/account.py", line 81, in register
model.Session.commit()
File "/opt/pybossa-env/local/lib/python2.7/site-packages/sqlalchemy/orm/scoping.py", line 113, in do
return getattr(self.registry(), name)(_args, *_kwargs)
File "/opt/pybossa-env/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py", line 645, in commit
self.transaction.commit()
File "/opt/pybossa-env/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py", line 313, in commit
self._prepare_impl()
File "/opt/pybossa-env/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py", line 297, in _prepare_impl
self.session.flush()
File "/opt/pybossa-env/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py", line 1547, in flush
self._flush(objects)
File "/opt/pybossa-env/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py", line 1616, in _flush
flush_context.execute()
File "/opt/pybossa-env/local/lib/python2.7/site-packages/sqlalchemy/orm/unitofwork.py", line 328, in execute
rec.execute(self)
File "/opt/pybossa-env/local/lib/python2.7/site-packages/sqlalchemy/orm/unitofwork.py", line 472, in execute
uow
File "/opt/pybossa-env/local/lib/python2.7/site-packages/sqlalchemy/orm/mapper.py", line 2220, in _save_obj
execute(statement, params)
File "/opt/pybossa-env/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 1399, in execute
params)
File "/opt/pybossa-env/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 1532, in _execute_clauseelement
compiled_sql, distilled_params
File "/opt/pybossa-env/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 1640, in _execute_context
context)
File "/opt/pybossa-env/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 1633, in _execute_context
context)
File "/opt/pybossa-env/local/lib/python2.7/site-packages/sqlalchemy/engine/default.py", line 330, in do_execute
cursor.execute(statement, parameters)
File "build/bdist.linux-x86_64/egg/MySQLdb/cursors.py", line 174, in execute
self.errorhandler(self, exc, value)
File "build/bdist.linux-x86_64/egg/MySQLdb/connections.py", line 36, in defaulterrorhandler
raise errorclass, errorvalue
IntegrityError: (IntegrityError) (1062, "Duplicate entry '[email protected]' for key 'email_addr'") 'INSERT INTO user (create_time, email_addr, name, passwd_hash, category, flags, info) VALUES (%s, %s, %s, %s, %s, %s, %s)' (1327584585.0, '[email protected]', 'nigini', 'sha1$xHOAZIra$6b653bf5193cb974d350af14ee972a71a3663323', None, None, '{}')

• Location: /app/new
• Need to be logged in ...
• Creator becomes owner

Have a form:

• Fields: Title, Slug (short_name), Description, Image, ....

@nigini @rgrp I was thinking that it could be interesting to get more people involved if we include the Github ribbon Fork me in the top right corner linking to this site. What do you think?

• CRUD for core domain objects (App, Task, TaskRun, User)
• Support (and requirement) of API keys - see #20