Add restriction on the file-size of the uploaded logo (1.5 Mb).
This depends on invenio-files-rest which should implement such feature, thus on the logo's part it's just a matter of intgrating with it during ObjectVersion initialization.

• Use a sub-class of the Request model to track member inclusion requests
• Adjust the programmatic APIs
• Adjust REST API endpoints to /api/communities<comid>/requests/members (moved to #174)

• Discuss and figure out the UI views in accordance with the previously defined use cases.
• Create Mockups and solidify the basic functions of each page.

The goal is to create a minimal functioning UI for the various CRUD operations that take place around a community, using the /api/communities endpoints. Styling and general UX enhancements will be addressed in the next iteration.

• Create form -/communities/new (React) (0.5d)
• Settings page (with edit) -/communities/<comid>/settings (React) (0.5d)
• Search -/communities/search (React) (0.5d)
• Community index -/communities/ (Jinja) (1d)
• Community item - /communities/<comid> (Jinja + React) (1d)

• Community record search
• Record inclusion requests
  • For the record creator:
    • On record landing page have a popup to allow adding/removing commuities
    • On the community page
      • "Do you want to upload a record in this community?"
      • "Do you want your record to be included in this community?"
    • List/search user records pending curation
  • For the community curator (/communities/<comid>/curate)
    • List/search records pending curation (Q: merge with "Community record search"?)
      • Accept/reject/comment buttons

When accessing the communities page provided by invenio-communities there is an Internal Server Error if user registration is off ( SECURITY_REGISTERABLE=False) and being logged out.
The reason can be found here. There is no registration endpoint, because registration is deactivated.

In the invenio-accounts module the problem is solved by adding a

{%- if security.registerable %}
# Sign-up button
{%- endif %}

block around the signup-button. (see here)

I could provide a pull request, if you wish to.

request.is_xhr has been deprecated in werkzeug>=0.13

• Add the decided pages in a UI blueprint.
• Add JS (React for the functionality of your pages)

• add tests for last modified header.

Initially REST API E2E-style tests to stabilize the request/response format

The search by title is not parsing unicode characters properly (and failing).

This works:
https://zenodo.org/communities/?p=Image+Knowledge+Gestaltung.+An+Interdisciplinary+Laboratory%2C+Cluster+of+Excellence+at+the+Humboldt-Universit

but adding extra character "ä" to the search yields not results:

https://zenodo.org/communities/?p=Image+Knowledge+Gestaltung.+An+Interdisciplinary+Laboratory%2C+Cluster+of+Excellence+at+the+Humboldt-Universit%C3%A4

models.py

• Since we're looking into having flexible metadata schemas for Communities (to allow e.g. plugins that introduce vocabularies), the existing table model wouldn't fit these requirements
• Sub-classing RecordMetadata, would allow a separate place for storing community (meta)data
• To keep track of community identifiers a PersistentIdentifier can be used

api.py

• To use the new model, the Record.model_cls, would allow for a flexible API class

Missing CERN special waiver.

And add deprecation warning
and release v1.0.0a20

Members listing

• Model
  • Storage
  • Metadata model (roles, ???)
• API class
• REST API - /api/communities/<comid>/members

Member invitation/request

• Model
• API class
• REST API - /api/communities/<comid>/invitations

Check MathJax

The package contains examples/app.py example application, but there is no test
for it in tests/test_example_app.py. It should be added. See existing examples:

• https://github.com/inveniosoftware/invenio-records/blob/master/tests/test_example_app.py
• https://github.com/inveniosoftware/invenio-marc21/blob/master/tests/test_example_app.py

Extend and list the use case scenarios, preferably in a Markdown Document.

• From the record owner’s PoV
• From the community admin/curator’s PoV

Define API views to handle the previously defined use cases.

• Use mixins from records and members programmatic APIs to dynamically configure the Community API class
• Align methods with records API (as_dict, properties, etc.)

The results on invenio_community.curation endpoint should return the result set filtered by the provisional_community key.

This is done through the parameter in angular app, namely <invenio-search search-hidden-params='{"provisional_community": "{{ community.id }}"}'>. This, however, doesn't seem to work.

Exactly the same solution works for endpoint invenio_community.detail, which filters the result by {"community": "{{ community.id }}"}.

• Use Semantic-UI for all pages
  • Header
  • Forms
  • Search pages
• Make sure all pages are properly linked between them
• Put "Coming soon" links where needed

• following discussion in inveniosoftware-contrib/invenio-groups#39 (comment)
• addresses #61

cc @lnielsen

Broken links

• check existing API functionality
• add missing important API functionality
• check API function signatures and parameters
• enhance API docstrings (param, returns, raises, versionadded)
• plug API functions to existing docs

I'm a curator of a community that has a quote in its name. When someone uploads a new record for that community, the alerting email reads:

A new upload requests to be added to your community (Tibor Simko's test community):


Record Title: World historical and predicted populations in percentage
Record Description: This is a test submission with a CSV file.

You can accept or reject this record in your community curation page:
('https://sandbox.zenodo.org/communities/tiborsimko-test-community/curate/',)

Note ' in the community name, and ' before/after URLs.

The former can be avoided, and for the latter I'd suggest to print the URL on an empty line without any enclosing brackets. Or at least use <...> instead of (...) as per RFC 1738 that many MUAs support.

The following cookiecutter change:

inveniosoftware/cookiecutter-invenio-module#98

should be propagated to this Invenio module.

Namely, in run-tests.sh, the sphinx for doctests is invoked after pytest run:

$ tail -3 ./\{\{\ cookiecutter.project_shortname\ \}\}/run-tests.sh
sphinx-build -qnNW docs docs/_build/html && python setup.py test && sphinx-build -qnNW -b doctest docs docs/_build/doctest

This sometimes led to problems on Travis CI with the second sphinx-build run due
to "disappearing" dependencies after the example application was tested.

A solution that worked for invenio-marc21 (see
inveniosoftware/invenio-marc21#49 (comment))
and that was integrated in cookiecutter (see
inveniosoftware/cookiecutter-invenio-module#98) was to
run doctest execution in pytest, removing the second sphinx-build invocation.

This both solved Travis CI build failures and simplified test suite execution.

Note that this change may necessitate to amend the code tests etc so that things
would be executed with the Flask application context (see
inveniosoftware/invenio-marc21@09e98fc).

Create a JSON Schema and mapping composed by useful metadata regarding the Community Record relationship e.g. messages/comments, users handling the requests etc.

Communities filtering uses the regular case-sensitive like clause in the search query. Using the case-insensitive ilike is probably more appropriate in order to emulate Elasticsearch behavior.

As discussed here: #76 (comment)

It would be nice to set up an relationship between OAISet and Community instead of using a model property:

if COMMUNITIES_OAI_ENABLED:
    from invenio_oaiserver.models import OAISet
    Community.oaiset = db.relationship(
        OAISet, primaryjoin=OAISet.spec==Community.oaiset_spec, viewonly=True)

• introduce new documentation structure inveniosoftware/cookiecutter-invenio-module#56
• document user perspective
• document signals (if not done)
• document example app (if not done)

Community records search

• Model
• API class
• REST API - /api/records/?community=<comid> vs. /api/communities/<comid>/records

Record inclusion requests

• Model
• API class
• REST API - /api/communities/<comid>/inclusion-requests/<irid>

• REST API
  • Core (CRUD)
  • Members
  • Records
• UI views
  • Core (CRUD)
  • Members
  • Records

The model currently depends on bibupload:

• https://github.com/inveniosoftware/invenio-communities/blob/master/invenio_communities/models.py#L349
• https://github.com/inveniosoftware/invenio-communities/blob/master/invenio_communities/models.py#L361

It should be the last modules and then I can remove it from invenio with my PR inveniosoftware/invenio#3470
Can we find a way to remove this dependency?

When a curator lands on the community page, there is no link to the /communities/my-community/curate facility. It would be useful to detect whether the person is a curator, and display useful links on the community page, notably the link to curate records, possibly with the number of pending requests.

As discussed IRL with @lnielsen and during DR meeting.

Why:

Reason 1:
Current design require that every reference needs to be updated when the community is renamed.

Reason 2
B2Share would like to use this module. It is quite probable that it will have to support the migration of a community from one server to another. In order to avoid conflicts it would be needed to have unique identifiers for Communities.

Reason 3
B2Share builds endpoints on top of the communities REST API endpoint. One of those endpoints is the communities' schemas /api/communities//schemas/.
If the community is renamed every record cannot validate anymore. We could update the current records but all the previous versions become hard to work with.

Reason to keep a user friendly id in a separate field:
Zenodo has an endpoint for each community. Thus it needs a unique human friendly name for each community.

Who needs it:

• Zenodo for reason 1
• B2Share for reasons 1 and 2

Flask-WTF v0.14.2 doesn't remove the csrf_token field from the Form.data any more, making the Community creation view to fail here.

Possible solutions:

• data.pop("csrf_token")
• Make a PR to Flask-WTF to recover this behavior (I suspect we're not the only people expanding form.data in function calls)
• Define forms using WTForms-Alchemy as already done in invenio_oauth2server.forms, and retrieve the data using form.populate_obj(c).

Include the core functionality for the model manipulation in API classes.

• Members list - /communities/<comid>/members
  • Members table
  • Member invite modal (different for admin/user)
  • Invitations list modal
• Member invitation - /communities/invitation?token=...
  • Accept/reject button

(Hope this is the right repo, I apprecciate a pointer if this is the wrong place to suggest this.)

It would be great if multiple people could administer a community/collection.

Figure out (Discuss) which are the fields needed to be present on a DB level in regard to the use case scenarios.

See Records-REST for details.
HTML link should also be included.
Should also be added in the HTTP Headers (https://tools.ietf.org/html/rfc5988)

proof-read (including inflections)