Skip to content

Conversation

@barborico
Copy link
Contributor

@barborico barborico commented Oct 24, 2025

Overview of Changes

Descriptions are important for usability and auditability--let's let Access deployers make them required! This PR adds support for an environment variable REQUIRE_DESCRIPTIONS which, if set to True, will make descriptions required when creating/editing apps, groups, and tags.

Front end environment loading

I made another change (the second commit) to how Vite loads environment so that it will pull variables set in .env files, but will still use the process env as the final source of truth. This was necessary to be able to test the frontend conditional form field requirements locally (or other config-based behavior like the web app name).

Before: Only read from shell/system environment
Now: Read from both .env files AND shell environment, with shell taking precedence

Partial updates for apps, groups, and tags

To more consistently support Marshmallow's default loading without clearing properties omitted in a PUT request, I've updated the schema loading to apply partial updates.

Testing

With REQUIRE_DESCRIPTIONS=True:
image

With REQUIRE_DESCRIPTIONS=False or omitting the variable altogether, the original behavior is preserved.

@barborico barborico changed the title Make app, group, and tag descriptions required Make app, group, and tag descriptions requirable Oct 29, 2025
@barborico barborico requested a review from eguerrant October 29, 2025 16:53
Copy link
Contributor

@eguerrant eguerrant left a comment

Choose a reason for hiding this comment

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

If possible, please add tests for these changes

APP_NAME = os.getenv("APP_NAME", "Access")

# Require descriptions for apps, groups, and tags
REQUIRE_DESCRIPTIONS = os.getenv("REQUIRE_DESCRIPTIONS", "False") == "True"
Copy link
Contributor

@eguerrant eguerrant Oct 29, 2025

Choose a reason for hiding this comment

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

Feel free to leave as is but since the bool is being ingested as a string, would we want to be more flexible and allow things like 'true', 'True', 'TRUE' etc?

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.

4 participants