Skip to content
This repository has been archived by the owner on Aug 28, 2023. It is now read-only.

query risk data #367

Merged
merged 10 commits into from
Dec 22, 2017
Merged

query risk data #367

merged 10 commits into from
Dec 22, 2017

Conversation

flibbertigibbet
Copy link
Contributor

@flibbertigibbet flibbertigibbet commented Dec 21, 2017

Overview

Modifies API risk endpoint to serialize related models. Query for actual risk data in UI and use it in vulnerability assessment page.

Also adds endpoints for community systems and all (not just organization) weather events.

Demo

screenshot from 2017-12-21 14-59-05

Notes

Breaks adaptive need boxes, as they expect numeric input, but API returns strings.

Connects #322


class Meta:
model = WeatherEvent
fields = ('name', 'coastalOnly', 'concern', 'indicators', 'displayClass')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To avoid making pointless API calls when using WeatherEventSerializer as a part of OrganizationRiskSerializer, consider splitting it into two classes like so:

class WeatherEventSerializer(serializers.ModelSerializer):
    coastalOnly = serializers.BooleanField(source='coastal_only')
    # Other fields

    class Meta:
        model = WeatherEvent
        fields = ('name', 'coastalOnly', 'indicators', 'displayClass')

class WeatherEventWithConcernSerializer(WeatherEventSerializer):
    concern = ConcernSerializer()

    class Meta:
        fields = ('name', 'coastalOnly', 'concern', 'indicators', 'displayClass')

Then you can continue to use WeatherEventSerializer in OrganizationRiskSerializer and use WeatherEventWithConcernSerializer in the WeatherEventRankSerializer

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you saying we should exclude concerns from the weather events serialized with the organization risks?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes


constructor(private apiHttp: PlanItApiHttp) {}

risks(): Observable<Risk[]> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we're going to follow-up to this with delete/create/update methods as well, consider naming this list() so we can have a consistent naming scheme

To directly serialize all weather events in the system.
Serialze community systems in DRF API.
Serialize related community systems and weather events on risks DRF API endpoint,
instead of just the object ID.
Also add risk service (not yet used).
Copy link
Contributor

@maurizi maurizi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎉 Looks good - just make sure to fix the typo I noted and this is good to merge.

impactMagnitude?: string;
impactDescription?: string;
adaptiveCapacity?: string;
relativeAdaptiveValues?: string[];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo: This should be relatedAdaptiveValues

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good find

def get_serializer_class(self):
if self.action == 'update' or self.action == 'create' or self.action == 'partial_update':
return OrganizationRiskCreateSerializer
return OrganizationRiskSerializer
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

Use actual risk endpoint response instead of dummy data.
For use in autocomplete controls.
Use related object IDs on create, but serialize full objects.
For ranked weather events, continue to serialize full related concern.
Use "list" for consistency.
Remove unused imports.
@flibbertigibbet flibbertigibbet merged commit c43ae50 into azavea:develop Dec 22, 2017
@flibbertigibbet flibbertigibbet deleted the feature/kak/implement-va-functionality#322 branch December 22, 2017 16:04
@flibbertigibbet flibbertigibbet changed the title WIP: query risk data query risk data Dec 22, 2017
CloudNiner pushed a commit that referenced this pull request Dec 22, 2017
CloudNiner pushed a commit that referenced this pull request Dec 22, 2017
CloudNiner pushed a commit that referenced this pull request Dec 22, 2017
CloudNiner pushed a commit that referenced this pull request Dec 22, 2017
CloudNiner pushed a commit that referenced this pull request Dec 22, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants