| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Taxonomy > Category > Section
This commit adds models for it.
https://doc.incommon.cc/#classifications
|
| | |
|
|/
|
|
| |
from the data
|
| |
|
|
|
|
| |
edit categories
|
| |
|
| |
|
|
|
|
|
|
| |
This implements resource listing and pagination.
See /resources
|
|
|
|
|
| |
A single worker in development enables in-context debug in the
error console in the browser.
|
|
|
|
|
|
|
|
|
| |
Since we're dealing with lots of resources, we need a way to
handle pagination. This gem seems to be the new kid on the block
and doing things right, including pagination by default an I18n
support. Let's see.
Kaminari: https://github.com/kaminari/kaminari
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Renamed `readme.txt` to `README.md` to stick to standard README case
and take advantage of Markdown formatting supported by code hosting
services.
Also fixed names in the content.
And added import method to the database.
|
|
|
|
|
|
|
| |
t.references already creates an index, so the second index
actually broke things.
You may need to rebuild the database!
|
|
|
|
|
|
|
|
| |
mail -> email since it's unambiguous
Also changed 'Concertes' source to 'ConcertES' since it is
the group name on IN COMMON and the name of the Agent, to
facilitate data import.
|
| |
|
|
|
|
|
|
| |
Resources will be stored as JSON, in the (GeoJSON) :feature column.
They are assigned an UUID upon creation if they don't comme with one.
They belong to an Agent.
|
| |
|
|
|
|
| |
file to explain LocationsParser.rb
|
|
|
|
| |
contains all the locations from the Dewey and Concertes data
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
CVE-2020-10663: Unsafe Object Creation Vulnerability in JSON (Additional fix)
CVE-2020-10933: Heap exposure vulnerability in the socket library
https://www.ruby-lang.org/en/news/2020/03/31/ruby-2-6-6-released/
|
|
|
|
| |
This is a first version of the application, to go beyond simple authentication.
|
|
|
|
|
|
|
| |
When using SSO, the Discourse sends a list of the user groups.
We take the opportunity to update Agency information for the user.
This is performed as a background job, as it involves networked
requests to the Discourse, e.g., to verify group ownership...
|
|
|
|
|
|
|
| |
The Agency class can `grant` and `revoke` roles for a given Agent and User.
Since it is primarily used in context of both an Agent and User, we add
convenience methods so that one can grant or revoke a role simply by passing
the desired role to the instance.
|
|
|
|
|
|
| |
Rails.application.credentials.talk_api_key is the key for user interaction
Rails.application.credentials.talk_api_admin is the username to use for administration
Rails.application.credentials.talk_api_admin_key is the admin API key
|
| |
|
|
|
|
|
|
| |
We use the DiscourseApi::Client to interact with https://talk.incommon.cc
discourse_api: https://meta.discourse.org/t/using-the-discourse-api-ruby-gem/17587
|
|
|
|
|
|
|
|
|
|
|
| |
The ApplicationController provides a `current_user` method (and
helper) to access the authenticated user (if any).
The WelcomeController provides minimal logic to authenticate
against DiscourseSSO.
Current state is that one can login and logout.
Views need a lot of work.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since IN COMMON is about collective management of data
we're using the concept of Agent to describe a group of
users acting together.
In ActivityPub terms, Agent will be the Actor when manipulating
data, so that any individual User (or application) member of this
Agent will be able to manipulate data on behalf of this Agent.
Therefore a User has many Agencies, and an Agent as well: the
Agency model allows not only to create a joint table between Agents
and Users, but also to manage User roles within the related Agent.
Roles are defined as:
- observer: one who can read and review or flag data
- editor: one who create or edit data
- maintainer: one who can edit data and manage maps
- leader: one who can manage roles
A User may have zero or more roles in an Agent.
A User without a Agency record for a specific Agent will only be
able to 'observe' public data from this Agent.
(Note that this is not currently specified, but matches existing
reflection on Agents)
https://doc.incommon.cc/#agents
|
|
|
|
|
|
|
|
| |
We're creating a minimal User model that will be filled from SSO.
We also configure Inflections so we can use SSO instead of Sso which
looks weird for a module named after an acronym.
Use Discourse as SSO: https://meta.discourse.org/t/using-discourse-as-a-sso-provider/32974
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pry is a great console enhancement for development.
You can navigate through code and object with `cd` and `ls`,
or use `show-method foo` to see how it's written...
Bitfields allow to store multiple flags in an efficient integer.
It will be used to keep track of a User's roles within an Agent.
Pry: https://pry.github.io/
Pry-Rails: https://github.com/rweng/pry-rails
Bitfields: https://github.com/grosser/bitfields
|
| |
|
| |
|
|
|