| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Since we must associate other models (e.g., classifications) to a Resource,
we use a composite model to save all changes inside a database transaction.
This approach makes it simpler to handle resources and their associations.
Work remains to fix the geolocation and reverse geolocation to ensure
these are in sync.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
To some it may be more straightforward to think of the members of
an Agent as "users". This commit accepts using `Agent#users` instead
of `Agent#members`, but warns developers that they should be using
the other method.
Since Agent has_many Users, the Principle of Least Surprise warrants
that `agent.users` does something.
But they're really members.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Ensure new users belong to an Agent
Users may come without the correct group information, leading
to a situation where they have no Agent assigned to them.
The application cannot handle this, so we ensure new users
are at least associated to the new Anonymous Agent.
2. Introduce a default avatar
Users coming without an avatar would see a broken view.
Now they're assigned a default avatar, which shows the IN COMMON
icon logo instead.
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
This commit creates a dedicated Map model and
moves the JavaScript from view to a Stimulus controller.
- Stimulus.js https://stimulusjs.org
- Leaflet.js https://leafletjs.org
Upcoming resources:
- https://discourse.stimulusjs.org/t/leafletjs-with-stimulusjs-on-rails-6/1343/4
- https://github.com/ghybs/leaflet-defaulticon-compatibility
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Turn `has_and_belongs_to_many` into `has_many :through`: now,
resources and sections are related through Classifications.
- Refactor usage of jsonb column to use ActiveRecord validations
- Attention! store_accessor:
NOTE: If you are using structured database data types (eg. PostgreSQL hstore/json, or MySQL 5.7+ json) there is no need for the
serialization provided by .store. Simply use .store_accessor instead to generate the accessor methods. Be aware that these
columns use a string keyed hash and do not allow access using a symbol.
NOTE: The default validations with the exception of uniqueness will work. For example, if you want to check for uniqueness with
hstore you will need to use a custom validation to handle it.
https://api.rubyonrails.org/classes/ActiveRecord/Store.html
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Taxonomy > Category > Section
This commit adds models for it.
https://doc.incommon.cc/#classifications
|
| |
|
|
|
|
| |
This implements resource listing and pagination.
See /resources
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
