6242bc3e2f
* [MM-70140] Remove experimental AD/LDAP login button color settings Remove the dead-code LdapSettings.LoginButtonColor / LoginButtonBorderColor / LoginButtonTextColor experimental settings. These values were plumbed into the client config but never consumed by the web or mobile clients, so no AD/LDAP login button was ever rendered or colored. Removes the fields from the server config struct and defaults, the client config payload, the Admin Console Experimental Features section, the webapp config type, related en.json strings, API definitions, docs, and test/default config fixtures. Co-authored-by: mattermost-code <matty-code@mattermost.com> * [MM-70140] Add test guarding removal of LDAP login button color keys Assert that GenerateLimitedClientConfig still emits LdapLoginFieldName under an LDAP license but never emits the removed LdapLoginButtonColor/BorderColor/ TextColor keys, guarding against reintroduction of the dead settings. Co-authored-by: mattermost-code <matty-code@mattermost.com> * [MM-70140] Remove LDAP login button colors from webapp LdapSettings type Keep AdminConfig LdapSettings in sync with the server model after the experimental AD/LDAP login button color settings were removed. Co-authored-by: mattermost-code <matty-code@mattermost.com> * [MM-70140] Update admin console index test after LDAP color removal Drop experimental/features from the ldap search expectation now that the AD/LDAP login button color settings are no longer under Experimental. Co-authored-by: mattermost-code <matty-code@mattermost.com> * Address PR feedback: remove test for removed LDAP login button color settings Per @lieut-data's review, drop TestGenerateLimitedClientConfigOmitsLdapLoginButtonColors; there's no need to perpetually test that a removed feature stays removed. * chore: retrigger CI after GitHub Actions service outage Co-authored-by: mattermost-code <matty-code@mattermost.com> * chore: retrigger CI after Actions service recovery Co-authored-by: mattermost-code <matty-code@mattermost.com> --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: mattermost-code <matty-code@mattermost.com> Co-authored-by: mattermost-build <mattermost-build@users.noreply.github.com>
Testing Text Processing
The text processing tests located in the doc/developer/tests folder are designed for use with the /test url command in isolated non-production test environments. This command posts the raw contents of a specified .md file in the doc/developer/tests folder into Mattermost.
Turning on /test
Access the System Console from the Main Menu. Under Environment > Developer make sure that Enable Testing Commands is set to true, then click Save. You may also change this setting from config.json by setting "EnableTesting": true. This setting is intended only for isolated non-production environments with test users and sample data, and must never be enabled in production. Changing this setting requires a server restart to take effect.
Running the Tests
In the text input box in Mattermost, type: /test url [file-name-in-testing-folder].md. Some examples:
/test url test-emoticons.md
/test url test-links.md
Notes:
- If a test has prerequisites, make sure your Mattermost setup meets the requirements described at the top of the test file.
- Some tests are over 4000 characters in length and will render across multiple posts.
Manual Testing
It is possible to manually test specific sections of any test, instead of using the /test command. Do this by clicking Raw in the header for the file when it’s open in GitHub, then copy and paste any section into Mattermost to post it. Manual testing only supports sections of 4000 characters or less per post.
Test plugins
There are three test plugins: testplugin.tar.gz, testplugin-v0.0.2.tar.gz, and testplugin2.tar.gz. These are use in some integration tests in the api4 package. Any changes to the plugin bundles require updating the corresponding signatures.
First, import the public and private development key:
gpg --import ./development-public-key.gpg
gpg --import ./development-private-key.asc
This has to be done only once.
Then update the signatures:
gpg -u F3FACE45E0DE642C8BD6A8E64C7C6562C192CC1F --verbose --personal-digest-preferences SHA256 --detach-sign testplugin.tar.gz
gpg -u F3FACE45E0DE642C8BD6A8E64C7C6562C192CC1F --verbose --personal-digest-preferences SHA256 --detach-sign --armor testplugin.tar.gz
gpg -u F3FACE45E0DE642C8BD6A8E64C7C6562C192CC1F --verbose --personal-digest-preferences SHA256 --detach-sign testplugin-v0.0.2.tar.gz
gpg -u F3FACE45E0DE642C8BD6A8E64C7C6562C192CC1F --verbose --personal-digest-preferences SHA256 --detach-sign --armor testplugin-v0.0.2.tar.gz
gpg -u F3FACE45E0DE642C8BD6A8E64C7C6562C192CC1F --verbose --personal-digest-preferences SHA256 --detach-sign testplugin2.tar.gz
gpg -u F3FACE45E0DE642C8BD6A8E64C7C6562C192CC1F --verbose --personal-digest-preferences SHA256 --detach-sign --armor testplugin2.tar.gz
Finally, include the updates bundles and signatures in your commit.
Image fixtures
The api4 package tests compare server-generated image thumbnails and previews against fixture files (e.g. orientation_test_1_expected_thumb.jpeg). Comparisons are pixel-based with a small tolerance, so minor encoder drift across patch releases is handled automatically.
However, Go's image/jpeg encoder has changed incompatibly across major versions (e.g. Go 1.25 → 1.26). When upgrading Go, regenerate the JPEG fixtures by running:
go test -run "TestUploadFiles/.*thumbnail" ./channels/api4/ -args -update-fixtures
go test -run "TestGenerateMiniPreviewImage" ./channels/app/imaging/ -args -update-fixtures
Run both from server/. Commit the updated fixture files alongside the Go version bump.