feat: add AccountSettingsReadOnlyFieldsRequested filter#334
feat: add AccountSettingsReadOnlyFieldsRequested filter#334pwnage101 wants to merge 2 commits intoopenedx:mainfrom
Conversation
1443652 to
a2bae8d
Compare
|
@pwnage101 I will try to review this afternoon. I know the big goal is to get rid of this import in the platform |
felipemontoya
left a comment
There was a problem hiding this comment.
There are some non conventional behaviours that should be easy to correct.
| set: the (possibly expanded) set of read-only field names. | ||
| """ | ||
| data = super().run_pipeline(readonly_fields=readonly_fields, user=user) | ||
| return data.get("readonly_fields", set()) |
There was a problem hiding this comment.
It is customary for filters to return the complete list of inputs that where passed to the filter.
I understand the intent, it would be a strange use case to have a filter such as AccountSettingsReadOnlyFieldsRequested return a different user object, but this is breaking the stablished pattern.
The filter should return something like:
return (
data.get("readonly_fields"),
data.get("user"),
)
On the other hand, you don't need to return an empty set() as the fallback. The only way for this to happen is for your implemented step to remove the key "readonly_fields" but that would only happen if the step is broken or if by design it is trying to break the pipeline and trigger some try-catch block. Returning a default here would interfere with the accepted mechanism.
| Tests for the AccountSettingsReadOnlyFieldsRequested filter. | ||
| """ | ||
|
|
||
| def test_run_filter_returns_empty_set_unchanged_when_no_pipeline(self): |
There was a problem hiding this comment.
Most tests for filters are really easy because they only test that whatever you pass in them is returned back when the step pipeline is empty. That should be enough when you take the filter definition changes into account.
ENT-11510
Blocks: