-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implements #611 -- Customizable location and relationship types #1429
Conversation
@oliverroick I can modify the indexing as needed to match the new schema. |
Regarding the export format, why are we including the tenure type label in the first place? We don't do the same for the location or party type or for any |
fd10811
to
83dd095
Compare
83dd095
to
263216a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code looks good except for some time things. Not sure if I fully understand the implications of the feature, maybe we can do a quick demo?
cadasta/core/form_mixins.py
Outdated
lang = get_language() | ||
default_lang = question.questionnaire.default_language | ||
|
||
for o in options: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the sake of clarity, can we iterate as for name, label in options:
?
cadasta/core/form_mixins.py
Outdated
except Question.DoesNotExist: | ||
pass | ||
else: | ||
types = [] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unnecessary redefinition of types
from line 15.
cadasta/core/form_mixins.py
Outdated
if include_labels: | ||
return types | ||
else: | ||
return [t[0] for t in types] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, for legibility can we call do something like [name for name, label in types]
so that it's more obvious what will be put in the array?
migrations.DeleteModel( | ||
name='HistoricalTenureRelationshipType', | ||
), | ||
] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason that we can't merge this with 0003_convert_tenuretype_to_charfield
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, I merged both
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple of broken things.
Just to confirm: when uploading a questionnaire, you still need to have labels for the choices? I think I'm confused by the get_types
tests that test not including labels.
cadasta/spatial/tests/test_models.py
Outdated
@@ -113,7 +117,65 @@ def test_adding_attributes(self): | |||
|
|||
def test_name(self): | |||
su = SpatialUnitFactory.create(type="RW") | |||
assert su.name == "Right-of-way" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did you change this test if it's supposed to test the name
property? Shouldn't name
and location_type_label
return the same thing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I first folded the functionality that is now in location_type_label
into name
but later decided that it should live in location_type_label
so it's consistent with TenureRelationship
.
I'll revert that so the test is for location_type_label
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ignore that. name
the test is for name
@@ -51,16 +49,16 @@ def validate_row(headers, row, config): | |||
|
|||
if location_type_field: | |||
location_type = _get_field_value(location_type_field, "location_type") | |||
type_choices = [choice[0] for choice in TYPE_CHOICES] | |||
type_choices = config['allowed_location_types'] | |||
if location_type and location_type not in type_choices: | |||
raise ValidationError( | |||
_("Invalid location_type: '%s'.") % location_type |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I entered a questionnaire with 'DR' as a location type choice, and it works in the UI. However, when I tried to import data, this error was raised saying 'DR' was an invalid location_type.
It didn't raise when I used one of the default location_type options, and it should have since I entered a custom quesitonnaire. Instead, the platform errored out when trying to load the locations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 That's fixed now.
cadasta/search/views/async.py
Outdated
@@ -172,12 +182,7 @@ def get_main_label(self, model, source): | |||
if model == SpatialUnit: | |||
return spatial_type_choices.get(source['type'], '—') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if I understand. Where is "Their Land" coming from? Is it defined in the Questionnaire?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it's the label defined in the questionnaire.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The custom labels weren't used in the search view. That's sorted now.
cadasta/party/serializers.py
Outdated
def validate_tenure_type(self, value): | ||
prj = self.context['project'] | ||
allowed_types = get_types('tenure_types', | ||
TENURE_RELATIONSHIP_TYPES, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This only allows default tenure choices to be used, so I can't update any custom types through the API:
{
"tenure_type": [
"'FU' is not a valid choice for field 'tenure_type'."
]
}
But if you query to tenure record, the type is set to FU, which is allowed...
{
"attributes": {},
"id": "8biusfwafn7zjnkphapjqutp",
"party": {
"id": "zgvyctdtxybxjri5upw2g9e4",
"name": "Fuzzy Wuzzy",
"type": "IN"
},
"rel_class": "tenure",
"spatial_unit": {
"geometry": {
"coordinates": [
131.02294921875,
31.484893386890164
],
"type": "Point"
},
"properties": {
"id": "p5sgtrjezgjsu7ujwdb6exeb",
"type": "TL"
},
"type": "Feature"
},
"tenure_type": "FU"
}
It works for custom location types
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, this should read allowed_types = get_types('tenure_type',
. Added tests as well.
Sooo. I addressed the requests. There's probably more work to be done, now that the search export is merged... Going to look into that this week. |
5460f1a
to
6a3ffa3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me. One comment about (I think) leftover code. Do we need to reassess the last commit now that search export is being reverted?
cadasta/search/views/async.py
Outdated
include_labels=True) | ||
self.spatial_types = dict(spatial_types) | ||
|
||
SPATIAL_TYPE_CHOICES |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this serving a purpose?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I obviously left it in there on purpose — the check whether you review carefully ;) Looks like you do.
It's removed now.
Just reiterating this question again. Regarding the export format, why are we including the tenure type label in the first place? We don't do the same for the location or party type or for any |
I agree that exporting the labels doesn't serve a particular purpose. I'd vouch for removing it from all exports. @dpalomino, what's your take on this? If we decide to keep the labels, then we should be consistent and add the labels everywhere. |
Thanks @oliverroick. Yes, I agree. I think with the tenure_type id and the location_type id should work. |
ac96768
to
393f556
Compare
393f556
to
0ab2bdd
Compare
Proposed changes in this pull request
This PR adds changes required to implement #611. The basic idea is that project managers can customise location and relationship types via the
location_type
ortenure_type
fields in a questionnaire. Only types defined in the questionnaire will be allowed. If the questionnaire does not define a question, standards types will be used.core
core.form_mixins.get_types
which returns a list of valid types of for a select field. It expects a question name (eithertenure_type
orlocation_type
) and returns all possible options if the question is defined for the given questionnaire ID. If no questionnaire ID is given or the question is not defined in the questionnaire,default
is returned. There's an addition option include labels for all choices.organization
config
:allowed_location_types
andallowed_tenure_types
. Both are generated usingcore.form_mixins.get_types
. They define the accepted types for the project. Imported tenure types and location types are validated against these lists.tenure_type.id
andtenure_type.label
were renamed totenure_type_id
andtenure_type_label
for imports and exports.cadasta/organization/tests/files/test_conditionals.xlsx
cadasta/organization/tests/files/test_download.xlsx
cadasta/organization/tests/files/test_one_to_many.xlsx
party
TenureRelationshipType
model and turned thetenure_type
field of theParty
model into a simpleCharField
. We originally implemented theTenureRelationshipType
in anticipation that we are going to implement custom tenure types. I decided not to useTenureRelationshipType
because we would have to store information about valid selections for tenure types in two places:TenureRelationshipType
andQuestionnaire
. Instead, I'm only storing that information with theQuestionnaire
and feed all forms, serializers, imports, exports from there.party.models.TENURE_RELATIONSHIP_TYPES
toparty.choices.TENURE_RELATIONSHIP_TYPES
to be consistent with other app.tenure_type
are defined viaparty.choices.TENURE_RELATIONSHIP_TYPES
.TenureRelationshipType
and falling back to simpleCharField
fortenure_type
has the following implications:TenureRelationship
s are indexed including the fieldtenure_type_id
, which isn't present any longer. This should be changed totenure_type
.validate_tenure_type
toparty.serializers.TenureRelationshipWriteSerializer
to make suretenure_types
are validated via the API.tenure_type_label
ofparty.models.TenureRelationship
to return the correct label for aTenureRelationship
.loadtenurereltypes
command as it is no longer relevant.ACQUIRED_CHOICES
fromparty.models.TenureRelationship
because it's not used anywhere.spatial
choices
parameter fromspatial.models.SpatialUnit
so accepted choices for the field are customisable.location_type_label
tospatial.models.SpatialUnit
to return the correct label for the location type.validate_type
tospatial.serializers.SpatialUnitSerializer
to make surelocation_types
are validated via the API.When should this PR be merged
Risks
Follow-up actions
Checklist (for reviewing)
General
migration
label if a new migration is added.Functionality
Code
Tests
Security
Documentation