Skip to content
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

[#119] Change set-field Web-API #128

Closed

Conversation

sancho20021
Copy link
Contributor

@sancho20021 sancho20021 commented Jul 24, 2022

Description

Problem: set-field route was used both for changing visibility
and setting new fields. This resulted in additional handling of the
situation where both field contents and visibility option are missing.

Solution: require contents for setting field and allow changing
visibility for convenience. Add set-field-visibility request
which modifies only visibility.

Question?

Currently in set-field-visibility I pass the value in the body of the request.
Maybe it would be better to pass it in the request string itself:

set-field-visibility/entry-path/field/private

I don't know.

Related issue(s)

Fixed part of #119. Refactor of CLI API still needed.

✅ Checklist for your Pull Request

Related changes (conditional)

  • Tests

    • If I added new functionality, I added tests covering it.
    • If I fixed a bug, I added a regression test to prevent the bug from
      silently reappearing again.
  • Documentation

    • I checked whether I should update the docs and did so if necessary:

Stylistic guide (mandatory)

Problem: `set-field` route was used both for changing visibility
and setting fields. This resulted in ambiguous behavior in case
of missing contents and visibility options.

Solution: require contents for setting field and allow changing
visibility for convenience. Add `set-field-visibility` request
which doesn't require field contents.
@Kariel-Myrr
Copy link
Contributor

Seems in issue description field visibility should be a query parametr

These issues can be solved by having a single endpoint that accepts an optional ?visibility=public/private query parameter and an optional FieldContents.

@sancho20021
Copy link
Contributor Author

Seems in issue description field visibility should be a query parametr

Yes but that was an initial proposal, we later decided to split our queries into set-field with indeed an optional visibility parameter and set-field-visibility.

I don't want the set-field-visibility to take visibility as a parameter because it would require repeating the word visibility two times:
/set-field-visibility/?visibility=private

@Kariel-Myrr
Copy link
Contributor

Ok, IMO it would be more logical to make it query. JSON looks like overshot. And seems nothing chain us to JSON format

@sancho20021
Copy link
Contributor Author

sancho20021 commented Jul 28, 2022

Ok, IMO it would be more logical to make it query. JSON looks like overshot. And seems nothing chain us to JSON format

Yeah, will redo.

@sancho20021
Copy link
Contributor Author

@Kariel-Myrr I moved visibility from JSON body to the query string. Now a request looks like

/set-field-visibility/public

Copy link
Contributor

@Kariel-Myrr Kariel-Myrr left a comment

Choose a reason for hiding this comment

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

LGTM

]
|]
-- unit_set_field_missing_field_contents :: IO ()
-- TODO: add test that expects an error in case of missing contents
Copy link
Contributor

Choose a reason for hiding this comment

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

Seems as unsolved TODO

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Resolved now, you can check how I did it, I'm not sure it is the proper way

void $ setField "dir/entry" "private-field" Nothing "contents"
void $ setField "dir/entry" "public-field" Nothing "contents"
changeFieldVisibility "dir/entry" "private-field" "private"
changeFieldVisibility "dir/entry" "public-field" "public"
Copy link
Contributor

Choose a reason for hiding this comment

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

Why there is two checks in one test?

If we're expecting to fail at once = one way (only private/public)
If it could fail on one, but not on second variant seems as two separate tests

I know that they're just doing the same thing, but we aren't short on test space)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed 👍

@@ -102,8 +102,8 @@ scrubDates =
cofferTest :: IO () -> IO ()
cofferTest test = deleteRecords >> test

setField :: Text -> Text -> Text -> IO (JsonResponse Value)
setField path name contents =
setField :: Text -> Text -> Maybe Bool -> Text -> IO (JsonResponse Value)
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not straight Maybe Visibility

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because in #105 it says:

And let's not use coffer's core data types/encoders/decoders, let's use json literals (e.g. with aesonQQ)

We don't import anything from coffer core so just for consistency I don't import Visibility too

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think I will change Bool to Text to unify the style with function changeFieldVisibility

@sancho20021 sancho20021 force-pushed the sancho20021/#119-refactor-set-field-endpoint branch from 72d11b0 to e5e088d Compare August 2, 2022 16:52
@sancho20021 sancho20021 closed this Aug 2, 2022
@sancho20021 sancho20021 reopened this Aug 2, 2022
@sancho20021
Copy link
Contributor Author

This PR is closed due to existing #130.

@sancho20021 sancho20021 closed this Aug 2, 2022
@sancho20021 sancho20021 deleted the sancho20021/#119-refactor-set-field-endpoint branch August 2, 2022 17:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants