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

Add draft of schema file #2

Merged
merged 9 commits into from
Jul 11, 2024
Merged

Add draft of schema file #2

merged 9 commits into from
Jul 11, 2024

Conversation

radishmouse
Copy link
Contributor

@radishmouse radishmouse commented May 2, 2024

Closes #1

The new schema.json includes the fields mentioned in the tech spec as well as:

  • descriptions of each field
  • a list of required fields

Please let me know if anything is missing or needs improvement!


Update: now includes a version of the schema generated by the pydantic model (from #5).
With the exception of the dependantRequired key , it is equivalent to the schema.json introduced by this PR.

@MelissaAutumn
Copy link
Member

cc @freaktechnik & @vDeo

Do you two have any questions, or concerns about this spec?

@radishmouse
Copy link
Contributor Author

I've got a more fields to add (thankfully, @Sancus alerted me to the missing fields), but won't be able to address until tomorrow

Copy link
Contributor

@freaktechnik freaktechnik left a comment

Choose a reason for hiding this comment

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

I just had a thought: we can handle localization with the locale filtering, so we have one of these objects per locale and just filter them.

schema.json Outdated
Comment on lines 14 to 23
"start_at": {
"type": "string",
"format": "date-time",
"description": "Timestamp after which Thunderbird will show the event after startup."
},
"end_at": {
"type": "string",
"format": "date-time",
"description": "Timestamp after which Thunderbird will never show the event, even if it has never been shown to the user."
},
Copy link
Contributor

Choose a reason for hiding this comment

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

I assume these will be ...T...Z timestamps? From the json schema docs I could find they didn't specify that it should include a timezone.

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 that including a timezone should be fine?
I couldn't find a validator that actually checked if a date-time string field was formatted correctly.

(The validators said everything was 👍 whether I put in a timestamp with/without a timezone...and even the string "this is not a timestamp")

Copy link
Member

Choose a reason for hiding this comment

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

This should always be UTC for consistency when we are publishing events. It's fine if the client is able to handle other time zones, but not required.

schema.json Outdated
},
"description": {
"type": "string",
"description": "A short paragraph that can contain HTML and will be displayed in the Thunderbird UI."
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should limit the allowed HTML so we can sanitize it and display it confidently. Obviously we can do this unilaterally in the client anyway, but maybe we'd want to define that somewhere.

schema.json Outdated Show resolved Hide resolved
@radishmouse
Copy link
Contributor Author

.

I just had a thought: we can handle localization with the locale filtering, so we have one of these objects per locale and just filter them.

@MelissaAutumn suggested something similar: maybe when the client requests the notifications, it sends a locale string as a parameter. That way, the server only sends back the locale-specific notifications.

schema.json Outdated
Comment on lines 56 to 61
"exclude": {
"$ref": "#/definitions/profile"
},
"include": {
"$ref": "#/definitions/profile"
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Should these be arrays of profile in case we want to target specific combinations? I don't love the arrays of arrays structure this would lead to though.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

🤔 making them arrays of profile is probably the best way to do combinations. But yeah, could be annoying to process on the client.

schema.json Outdated Show resolved Hide resolved
@freaktechnik
Copy link
Contributor

Mel suggested something similar: maybe when the client requests the notifications, it sends a locale string as a parameter. That way, the server only sends back the locale-specific notifications.

Right, but that would mean you're doing actual work on the server side. As I had mentioned, we should easily be able to do an URL similar to what the release notes have: https://searchfox.org/comm-central/rev/c04464d92274c9d2b8ec036d47b0c664adf1a45f/mail/app/profile/all-thunderbird.js#127

schema.json Outdated
"channels": {
"type": "array",
"items": {
"enum": ["esr", "release", "beta", "daily"],
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this would be default for builds that aren't on any channel, like local builds or possibly other "unbranded" builds. The SoW doesn't have any mention of that, just trying to think of all the permutations of what we might encounter in the wild.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's a good point. @Sancus, any objection to sending notifications to any/all builds by specifying default?

Copy link
Contributor

@freaktechnik freaktechnik May 3, 2024

Choose a reason for hiding this comment

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

Not sure it was clear, I meant the string default as enum value, so "default"

Copy link
Member

@Sancus Sancus May 14, 2024

Choose a reason for hiding this comment

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

E: Nevermind all that stuff. On further examination, there is actually a decent number of folks on the default channel, so yeah it makes sense to include that here. I'm guessing this is used by some distros for their package managed builds. It might be useful to target.

There ARE a lot of other minor channels but I don't think we need targeting for them in v1.

To target everybody NOT on a major channel I would still go with a blacklist.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👍

Question: Should I add a "denylist" to the schema? (and maybe change "targeting" to "allowlist"?)

Copy link
Contributor

Choose a reason for hiding this comment

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

Isn't that what exclude and include do?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

hahahaha yes.
😂

schema.json Outdated
"type": "array",
"items": {
"enum": [
"windows",
Copy link
Member

@Sancus Sancus May 16, 2024

Choose a reason for hiding this comment

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

I think these values should probably be the ones used by Thunderbird itself. That was my intent for all the targeting filters, that they mirror the values used internally in the client so Thunderbird doesn't need some crazy remapping scheme in comm-central.

I'm not sure what all possible values of %OS% are in Thunderbird. I think the major three are WINNT, Darwin, and Linux though. @jfx2006 might know or know where you can find lists of these things.

Copy link
Contributor

Choose a reason for hiding this comment

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

I've been looking at https://searchfox.org/mozilla-central/source/toolkit/modules/AppConstants.sys.mjs since that's what I get at runtime.

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

I've been looking at https://searchfox.org/mozilla-central/source/toolkit/modules/AppConstants.sys.mjs since that's what I get at runtime.

Ah, if it's easy for you to get that at runtime then nevermind, use that. Seems fine to me.

Copy link
Contributor

Choose a reason for hiding this comment

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

If we'd want to match it that'd still mean "win" and "macosx" as values though.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah definitely match, it will avoid having to maintain mappings on the client side.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👍 makes sense! I've updated those two enum values to match AppConstants.sys.mjs

@radishmouse
Copy link
Contributor Author

radishmouse commented Jun 7, 2024

@freaktechnik @Sancus The changes introduced by #5 include a command for generating a JSON schema from a pydantic model.

The pydantic model includes all the same enum values and constraints as the JSON schema in this PR.

Would it be reasonable to close this PR in favor of a generated schema file?
Alternatively, we could create another ticket to test the generated JSON schema more thoroughly.

@MelissaAutumn
Copy link
Member

MelissaAutumn commented Jun 7, 2024

@freaktechnik @Sancus The changes introduced by #5 include a command for generating a JSON schema from a pydantic model.

The pydantic model includes all the same enum values and constraints as the JSON schema in this PR.

Would it be reasonable to close this PR in favor of a generated schema file? Alternatively, we could create another ticket to test the generated JSON schema more thoroughly.

Hey @radishmouse can you commit a current copy of that schema to repo for reference? And a general note it is missing the dependantRequired key (#7) but is otherwise matching.

@radishmouse
Copy link
Contributor Author

@MelissaAutumn generated schema added to this PR

Also, I updated the PR description making it clear that the generated schema is missing the dependantRequired key (but otherwise matches).

@freaktechnik
Copy link
Contributor

freaktechnik commented Jun 10, 2024

I assume all the optional keys being nullable is a side effect of what it's being generated from?

I think the manually written schema currently captures some less formal conventions on the interface, which the generated schema doesn't document.

@radishmouse
Copy link
Contributor Author

It sounds like the manually written schema is preferred. I'll merge this PR and update the JSON validation GH action to use it.

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.

Create JSON schema for notifications
4 participants