Related to #15758
Changes:
- Updated the copyright year in email templates to be set to the current
year when the email is sent.
Testing steps:
1. Configure a local Fleet instance to send emails to Mailpit
2. Activate SMTP to send a test email.
3. Invite a new user to the Fleet instance.
4. Change the email address of a user.
5. Log out of the Fleet instance and send a password reset email.
6. Go to the Mailpit dashboard and look at the copyright years in the
emails sent by the Fleet instance
Closes: #14246
Changes:
- Added a new key to the rituals YAML configuration: `autoIssue.repo`.
This value should be a string that is the name of the GH repo that
issues for the ritual should be created in.
- Updated ritual validation in `build-static-content`.
- Added support for the "monthly" ritual frequency for rituals with an
`autoIssue` value.
- Updated the `create-issues-for-todays-rituals` script to create GitHub
issues for rituals.
---------
Co-authored-by: Mike McNeil <mikermcneil@users.noreply.github.com>
Co-authored-by: Sam Pfluger <108141731+Sampfluger88@users.noreply.github.com>
for #15916, explanation of the rationale in the description of
`isMisreportedDecryptionError` and in the issue comments.
I refactored the code a little bit, trying to make it easier to follow
even with the added complexity.
This also paves the road for #15711
The new script was used for the fleetd v1.20.0 release #15991:
```
/path/to/fleet/tools/tuf/promote_edge_to_stable.sh orbit 1.20.0
/path/to/fleet/tools/tuf/promote_edge_to_stable.sh desktop 1.20.0
```
And to release osqueryd 5.11.0 to stable the following can be executed:
```
/path/to/fleet/tools/tuf/promote_edge_to_stable.sh osqueryd 5.11.0
```
Closes: #16018
Changes:
- Updated the testimonial configuration in testimonial.yml to add two
new required values:
- `quoteAuthorProfileImageFilename` - The filename of the quote author's
LinkedIn profile picture in the website's `assets/images/` folder
- `productCategories`: An array of product categories that this quote is
relevant to
- Added new quotes to testimonials.yml
- Updated the testimonial validation in build-static-content to throw an
error if a testimonial is missing one of the new required values
- Updated the `<scrollable-tweets> component to match the latest
wireframes
- Updated the controllers for the product category landing pages to
filter testimonials by product category and sort them by the order
specified in [the
wireframes](https://www.figma.com/file/3he8e72251IEnF6dBafKq1/%F0%9F%9A%A7-fleetdm.com-(scratchpad)?type=design&node-id=9369-4714&mode=dev)
- Pull info about duration-based settings to the top to make it clear.
For this bug: #15926
- Add info about self-managed v. managed-cloud customers
- Cut content
#15557
Following the precedent that Lucas used for other similar PRs, the best
way to review is probably by commits.
* The first one simply copies over the files from the fork to the
monorepo
* Second one adjusts all import paths
* Third one tidies up the `go.mod` files
* Last one fixes the linter issues in the nanomdm package
# Checklist for submitter
- ~~Changes file added for user-visible changes in `changes/` or
`orbit/changes/`.~~ (not a user-visible change)
- [x] Manual QA for all new/changed functionality (ran test suite,
re-generated mocks)
I also verified that our Go test suite did run the newly moved `nanomdm`
package steps:
```
ok github.com/fleetdm/fleet/v4/server/mdm/nanomdm/cryptoutil 0.003s coverage: 0.0% of statements in github.com/fleetdm/fleet/v4/...
ok github.com/fleetdm/fleet/v4/server/mdm/nanomdm/mdm 0.005s coverage: 46.2% of statements in github.com/fleetdm/fleet/v4/...
ok github.com/fleetdm/fleet/v4/server/mdm/nanomdm/service/certauth 1.320s coverage: 20.7% of statements in github.com/fleetdm/fleet/v4/...
ok github.com/fleetdm/fleet/v4/server/mdm/nanomdm/storage/file 0.007s coverage: 24.1% of statements in github.com/fleetdm/fleet/v4/...
```
noticed while working on #15916, we do a request that, when successful,
returns a 204 response (with no content)
currently the client will fail to parse the contents of the response and
return an error "response: unexpected end of JSON input, body" even if
the request was succesful.
This PR adds support for CIS Controls for macOS 14 - Sonoma.
The CIS Control changes from macOS 13 to 14 was minimal:
- Removed 5.9
- Added 2.18.1
- tested by running the test profile (ee/cis/macos-14/test/profiles/on-device-dictiation-enabled.mobileconfig)
---------
Co-authored-by: Sharon Katz <121527325+sharon-fdm@users.noreply.github.com>
> 📜 Related issue: #15538
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
<!-- Note that API documentation changes are now addressed by the
product design team. -->
- [x] Changes file added for user-visible changes in `changes/` or
`orbit/changes/`.
See [Changes
files](https://fleetdm.com/docs/contributing/committing-changes#changes-files)
for more information.
- [x] Added/updated tests
- [x] Manual QA for all new/changed functionality
> 📜 Related issue: #15635
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
<!-- Note that API documentation changes are now addressed by the
product design team. -->
- [x] Changes file added for user-visible changes in `changes/` or
`orbit/changes/`.
See [Changes
files](https://fleetdm.com/docs/contributing/committing-changes#changes-files)
for more information.
- [x] Added/updated tests
- [x] Manual QA for all new/changed functionality
Tests were added in the scep repo:
https://github.com/fleetdm/scep/pull/1
This new `:incoming` label is used by engineers to filter down to _new_
bugs on their sprint board during each standup. They will remove the
label, indicating they have triaged the issue.
QA removes `:reproduce`, EM removes `:incoming`.
- Move "Scalability testing" to Engineering section. Engineering team
will have a better idea if the story needs load testing
---------
Co-authored-by: Luke Heath <luke@fleetdm.com>
We will begin conducting postmortems for critical bugs in addition to
outages.
1. How was the bug introduced?
2. What is the gap in our testing process that we didn't find the bug
before it was released?
3. How are we going to change our testing (both manual and automated) so
that we will catch a similar bug in the future?
Why? We want to start evaluating the three questions above for every
critical bug so that we can learn and improve our processes.
Eric