-
Notifications
You must be signed in to change notification settings - Fork 699
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
added functionality to create new facility on existing kolibri #11197
added functionality to create new facility on existing kolibri #11197
Conversation
export const Presets = Object.freeze({ | ||
FORMAL: 'formal', | ||
NONFORMAL: 'nonformal', | ||
}); |
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.
Hi @Jaspreet-singh-1032. There looks to be similar constants in kolibri/plugins/setup_wizard/assets/src/constants.js
, so I think its better to use them instead for maintenance purposes!
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.
We can always move this to a more central location to eliminate the deep paths(ie ../../../../../)
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.
Hi @akolson, I have made some changes. Have a look and let me know if it needs any other changes.
Thanks.
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.
Maybe a clean up of this? Looks like Presets
has been moved to kolibri/core/assets/src/constants.js
so nolonger necessary in here
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.
Hi @Jaspreet-singh-1032 and @rtibbles, this is implemented exactly as specified in #10826 however I can see the following potential issues with this implementation:
- The user is presented with an option to choose between a non-formal and formal facility however since the rest of the steps from the setup wizard are missing the created facility is actually created with all the facility settings set to true regardless of the option I've selected. Thus the default Settings of a formal facility look like this:
- For the above mentioned reason there is no admin user in the created facility so that user has to be added separately if one wants to be able to import it on another device.
- The 'Add facility' button and the 'Create a new learning facility' modal are not yet localized in other languages.
value: 'create_new_facility', | ||
}, | ||
]; | ||
}, |
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 think label
fields should be translated. Is this a temporal measure? cc @rtibbles
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.
It would also be good to add the value
fields as constants in kolibri/plugins/device/assets/src/constants.js
as they seem specific to the device plugin
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.
Yes, the label values should be translated strings.
data() { | ||
return { | ||
facilityName: '', | ||
preset: 'nonformal', |
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.
We probably want to now use the Presets.NONFORMAL
here instead of hardcoded nonformal
string.
@@ -389,6 +420,13 @@ | |||
this.$emit('failure'); | |||
}); | |||
}, | |||
handleSelect(option) { | |||
if (option.value == 'import_facility') { |
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.
See my comments on value
fields above
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.
Generally code looks good, thanks @Jaspreet-singh-1032. There's is just a few clean up tasks to do and we should be good. Its probably good to hold off any further approvals in light of @pcenov's comments.
For @pcenov's points:
So - to get this merged, I would say we need to address 1. |
|
||
class Meta: | ||
model = Facility | ||
fields = ("id", "name", "preset") |
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.
You are taking the preset here, but not doing anything with it.
See here for an example of how the preset data is used in a serializer in order to set the settings appropriately: https://github.com/learningequality/kolibri/blob/release-v0.16.x/kolibri/core/device/serializers.py#L139
This would require adding a create
method to this serializer to implement this custom logic.
Hi @Jaspreet-singh-1032 please let me know when this one is ready for another round of manual testing. Thanks! |
Hi @pcenov, this is ready for testing. |
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.
Confirmed - the presets for Formal and Non-formal facility are implemented correctly now. Good to go!
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.
Thanks @Jaspreet-singh-1032! Please see some additional thoughts here, that I think would be the final piece for the merge. Unless @rtibbles has any other thoughts, we should be good after this.
) | ||
facility.dataset.reset_to_default_settings(validated_data.get("preset")) | ||
return facility | ||
|
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.
@Jaspreet-singh-1032 thanks for adding the create
method. However, here are a few more comments to further make the code more robust;
- You could set the
preset
andname
fields as variables instead eg.preset = validated_data.get("preset")
- Then add some validation checks to these variables before proceeding to use them. You can alternatively use the
validate
method within the serializer class if you like - It's also a good idea to wrap the code around a try..catch block just in case any of the transactions fail
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.
Hi @akolson, I've made the changes you suggested by setting preset
and name
fields as variables. However, I have not added additional validation to these variables because I believe the data is already being validated at this point. if there are specific scenarios or edge cases where you think further validation is needed, please let me know, and I'll be happy to implement it accordingly. And I have also added the try-catch block.
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 see the name
is being validated on the frontend, it's probably good to add this validation on the backend too. But, I could be lacking a bit of context overall so I am happy to proceed with the merge(Changes look good, thanks :)) as long as @rtibbles is happy with the changes.
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.
By default the serializer will do introspection of the Django model, so that should be doing some validation to ensure it doesn't exceed the maximum length of the name attribute, and that it is a string, so I think Django REST Framework magic is probably doing the leg work for us here!
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.
Great work @Jaspreet-singh-1032!
@@ -621,6 +622,13 @@ def annotate_queryset(self, queryset): | |||
) | |||
) | |||
|
|||
@decorators.action(methods=["post"], detail=False) | |||
def create_facility(self, request): | |||
serializer = CreateFacilitySerializer(data=request.data) |
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 think the only thing that this is missing is a permissions check here - we should require that request.user.is_superuser
is True
otherwise, we should raise a permissions error before doing anything else here.
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.
Excellent - yes using the permission classes in the decorator is a very neat way to do this!
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.
Adding a little blocker here in light of Richards comment on adding a permission check to the serializer. . We should be good for a merge once this check added.
Build breakage is caused by erroneous merge to develop, not by this PR. Merging! Great work @Jaspreet-singh-1032, this is really nicely done! |
Summary
closes #10826
Added functionality to create a new facility on the existing Kolibri
…
Testing checklist
PR process
Reviewer checklist
yarn
andpip
)