Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

72 lines
3.9 KiB
HTML
Raw Normal View History

<!DOCTYPE html>
2024-05-22 21:48:23 +01:00
<html th:lang="${#locale.language}" th:dir="#{language.direction}" th:data-language="${#locale.toString()}" xmlns:th="https://www.thymeleaf.org">
<head>
<th:block th:insert="~{fragments/common :: head(title=#{permissions.title}, header=#{permissions.header})}"></th:block>
</head>
2024-02-11 11:47:00 -05:00
<body>
<div id="page-container">
<div id="content-wrap">
<th:block th:insert="~{fragments/navbar.html :: navbar}"></th:block>
<br><br>
<div class="container">
<div class="row justify-content-center">
<div class="col-md-6 bg-card">
<div class="tool-header">
<span class="material-symbols-rounded tool-header-icon security">encrypted</span>
<span class="tool-header-text" th:text="#{permissions.header}"></span>
</div>
<p th:text="#{permissions.warning}"></p>
<form th:action="@{'api/v1/security/add-password'}" method="post" enctype="multipart/form-data">
<div class="mb-3">
<label th:text="#{permissions.selectText.1}"></label>
<div th:replace="~{fragments/common :: fileSelector(name='fileInput', multipleInputsForSingleRequest=false, accept='application/pdf')}"></div>
</div>
<div class="mb-3">
<label class="mb-2" th:text="#{permissions.selectText.2}"></label>
<div class="form-check ms-3">
Refactor permission variable names (#3457) ## Refactor: Improve clarity of permission variable names Renamed confusing `can[Action]` boolean variables to `prevent[Action]` (e.g., `canPrint` -> `preventPrinting`) in `PasswordController.java`, `AddPasswordRequest.java`, and `add-password.html`. The previous `can[Action]` convention was misleading, as `true` meant the action was *disallowed*. The new `prevent[Action]` naming directly reflects the intent (`true` = prevented), improving code clarity. **Changes:** * Updated variable names in controller logic * Updated `@Schema` descriptions in `AddPasswordRequest.java` * Updated corresponding HTML element attributes (`id`, `name`, `for`) in `add-password.html` **Important Notes:** * The underlying logic still inverts the boolean when setting permissions (e.g., `AccessPermission.setCanPrint(!preventPrinting)`). * User-facing UI text remains unchanged per request of @Frooodle in #3420. **Why not invert the API logic** * Inverting API (to can[action] logic) would either invalidate the UI * Inverting API AND changing UI would warrant bigger translation effort to change it in all languages * This version is consistent (meaning what the UI says is actually done) and preserve the UI language (meaning no translations needed) however it is inconsistent with PDFBox methods naming scheme **PDFBox** * **PDFBox Interaction:** This refactor addresses the naming *within* Stirling-PDF's API and Front-end layers only. The controller logic intentionally inverts the `prevent[Action]` boolean (`ap.setCanPrint(!preventPrinting)`) to correctly interact with the underlying PDFBox methods. No further renaming related to these permissions is necessary as the PDFBox methods themselves retain the `can[Action]` names. Underlying logic is not changed so it should work but just in case I tested locally on an Adobe PDF that contained form in Chrome. ## New variable names in API ![new API variable names](https://github.com/user-attachments/assets/f3d56aaf-0455-4f65-af14-c1a07a02d11a) **Related Issues:** Closes #3427 Closes #3420 --- ## Checklist ### General - [x] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [x] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md) (if applicable) - [x] I have performed a self-review of my own code - [x] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [x] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#6-testing) for more details.
2025-05-09 19:41:31 +02:00
<input type="checkbox" id="preventAssembly" name="preventAssembly">
<label for="preventAssembly" th:text="#{permissions.selectText.3}"></label>
</div>
<div class="form-check ms-3">
Refactor permission variable names (#3457) ## Refactor: Improve clarity of permission variable names Renamed confusing `can[Action]` boolean variables to `prevent[Action]` (e.g., `canPrint` -> `preventPrinting`) in `PasswordController.java`, `AddPasswordRequest.java`, and `add-password.html`. The previous `can[Action]` convention was misleading, as `true` meant the action was *disallowed*. The new `prevent[Action]` naming directly reflects the intent (`true` = prevented), improving code clarity. **Changes:** * Updated variable names in controller logic * Updated `@Schema` descriptions in `AddPasswordRequest.java` * Updated corresponding HTML element attributes (`id`, `name`, `for`) in `add-password.html` **Important Notes:** * The underlying logic still inverts the boolean when setting permissions (e.g., `AccessPermission.setCanPrint(!preventPrinting)`). * User-facing UI text remains unchanged per request of @Frooodle in #3420. **Why not invert the API logic** * Inverting API (to can[action] logic) would either invalidate the UI * Inverting API AND changing UI would warrant bigger translation effort to change it in all languages * This version is consistent (meaning what the UI says is actually done) and preserve the UI language (meaning no translations needed) however it is inconsistent with PDFBox methods naming scheme **PDFBox** * **PDFBox Interaction:** This refactor addresses the naming *within* Stirling-PDF's API and Front-end layers only. The controller logic intentionally inverts the `prevent[Action]` boolean (`ap.setCanPrint(!preventPrinting)`) to correctly interact with the underlying PDFBox methods. No further renaming related to these permissions is necessary as the PDFBox methods themselves retain the `can[Action]` names. Underlying logic is not changed so it should work but just in case I tested locally on an Adobe PDF that contained form in Chrome. ## New variable names in API ![new API variable names](https://github.com/user-attachments/assets/f3d56aaf-0455-4f65-af14-c1a07a02d11a) **Related Issues:** Closes #3427 Closes #3420 --- ## Checklist ### General - [x] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [x] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md) (if applicable) - [x] I have performed a self-review of my own code - [x] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [x] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#6-testing) for more details.
2025-05-09 19:41:31 +02:00
<input type="checkbox" id="preventExtractContent" name="preventExtractContent">
<label for="preventExtractContent" th:text="#{permissions.selectText.4}"></label>
</div>
<div class="form-check ms-3">
Refactor permission variable names (#3457) ## Refactor: Improve clarity of permission variable names Renamed confusing `can[Action]` boolean variables to `prevent[Action]` (e.g., `canPrint` -> `preventPrinting`) in `PasswordController.java`, `AddPasswordRequest.java`, and `add-password.html`. The previous `can[Action]` convention was misleading, as `true` meant the action was *disallowed*. The new `prevent[Action]` naming directly reflects the intent (`true` = prevented), improving code clarity. **Changes:** * Updated variable names in controller logic * Updated `@Schema` descriptions in `AddPasswordRequest.java` * Updated corresponding HTML element attributes (`id`, `name`, `for`) in `add-password.html` **Important Notes:** * The underlying logic still inverts the boolean when setting permissions (e.g., `AccessPermission.setCanPrint(!preventPrinting)`). * User-facing UI text remains unchanged per request of @Frooodle in #3420. **Why not invert the API logic** * Inverting API (to can[action] logic) would either invalidate the UI * Inverting API AND changing UI would warrant bigger translation effort to change it in all languages * This version is consistent (meaning what the UI says is actually done) and preserve the UI language (meaning no translations needed) however it is inconsistent with PDFBox methods naming scheme **PDFBox** * **PDFBox Interaction:** This refactor addresses the naming *within* Stirling-PDF's API and Front-end layers only. The controller logic intentionally inverts the `prevent[Action]` boolean (`ap.setCanPrint(!preventPrinting)`) to correctly interact with the underlying PDFBox methods. No further renaming related to these permissions is necessary as the PDFBox methods themselves retain the `can[Action]` names. Underlying logic is not changed so it should work but just in case I tested locally on an Adobe PDF that contained form in Chrome. ## New variable names in API ![new API variable names](https://github.com/user-attachments/assets/f3d56aaf-0455-4f65-af14-c1a07a02d11a) **Related Issues:** Closes #3427 Closes #3420 --- ## Checklist ### General - [x] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [x] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md) (if applicable) - [x] I have performed a self-review of my own code - [x] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [x] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#6-testing) for more details.
2025-05-09 19:41:31 +02:00
<input type="checkbox" id="preventExtractForAccessibility" name="preventExtractForAccessibility">
<label for="preventExtractForAccessibility" th:text="#{permissions.selectText.5}"></label>
</div>
<div class="form-check ms-3">
Refactor permission variable names (#3457) ## Refactor: Improve clarity of permission variable names Renamed confusing `can[Action]` boolean variables to `prevent[Action]` (e.g., `canPrint` -> `preventPrinting`) in `PasswordController.java`, `AddPasswordRequest.java`, and `add-password.html`. The previous `can[Action]` convention was misleading, as `true` meant the action was *disallowed*. The new `prevent[Action]` naming directly reflects the intent (`true` = prevented), improving code clarity. **Changes:** * Updated variable names in controller logic * Updated `@Schema` descriptions in `AddPasswordRequest.java` * Updated corresponding HTML element attributes (`id`, `name`, `for`) in `add-password.html` **Important Notes:** * The underlying logic still inverts the boolean when setting permissions (e.g., `AccessPermission.setCanPrint(!preventPrinting)`). * User-facing UI text remains unchanged per request of @Frooodle in #3420. **Why not invert the API logic** * Inverting API (to can[action] logic) would either invalidate the UI * Inverting API AND changing UI would warrant bigger translation effort to change it in all languages * This version is consistent (meaning what the UI says is actually done) and preserve the UI language (meaning no translations needed) however it is inconsistent with PDFBox methods naming scheme **PDFBox** * **PDFBox Interaction:** This refactor addresses the naming *within* Stirling-PDF's API and Front-end layers only. The controller logic intentionally inverts the `prevent[Action]` boolean (`ap.setCanPrint(!preventPrinting)`) to correctly interact with the underlying PDFBox methods. No further renaming related to these permissions is necessary as the PDFBox methods themselves retain the `can[Action]` names. Underlying logic is not changed so it should work but just in case I tested locally on an Adobe PDF that contained form in Chrome. ## New variable names in API ![new API variable names](https://github.com/user-attachments/assets/f3d56aaf-0455-4f65-af14-c1a07a02d11a) **Related Issues:** Closes #3427 Closes #3420 --- ## Checklist ### General - [x] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [x] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md) (if applicable) - [x] I have performed a self-review of my own code - [x] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [x] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#6-testing) for more details.
2025-05-09 19:41:31 +02:00
<input type="checkbox" id="preventFillInForm" name="preventFillInForm">
<label for="preventFillInForm" th:text="#{permissions.selectText.6}"></label>
</div>
<div class="form-check ms-3">
Refactor permission variable names (#3457) ## Refactor: Improve clarity of permission variable names Renamed confusing `can[Action]` boolean variables to `prevent[Action]` (e.g., `canPrint` -> `preventPrinting`) in `PasswordController.java`, `AddPasswordRequest.java`, and `add-password.html`. The previous `can[Action]` convention was misleading, as `true` meant the action was *disallowed*. The new `prevent[Action]` naming directly reflects the intent (`true` = prevented), improving code clarity. **Changes:** * Updated variable names in controller logic * Updated `@Schema` descriptions in `AddPasswordRequest.java` * Updated corresponding HTML element attributes (`id`, `name`, `for`) in `add-password.html` **Important Notes:** * The underlying logic still inverts the boolean when setting permissions (e.g., `AccessPermission.setCanPrint(!preventPrinting)`). * User-facing UI text remains unchanged per request of @Frooodle in #3420. **Why not invert the API logic** * Inverting API (to can[action] logic) would either invalidate the UI * Inverting API AND changing UI would warrant bigger translation effort to change it in all languages * This version is consistent (meaning what the UI says is actually done) and preserve the UI language (meaning no translations needed) however it is inconsistent with PDFBox methods naming scheme **PDFBox** * **PDFBox Interaction:** This refactor addresses the naming *within* Stirling-PDF's API and Front-end layers only. The controller logic intentionally inverts the `prevent[Action]` boolean (`ap.setCanPrint(!preventPrinting)`) to correctly interact with the underlying PDFBox methods. No further renaming related to these permissions is necessary as the PDFBox methods themselves retain the `can[Action]` names. Underlying logic is not changed so it should work but just in case I tested locally on an Adobe PDF that contained form in Chrome. ## New variable names in API ![new API variable names](https://github.com/user-attachments/assets/f3d56aaf-0455-4f65-af14-c1a07a02d11a) **Related Issues:** Closes #3427 Closes #3420 --- ## Checklist ### General - [x] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [x] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md) (if applicable) - [x] I have performed a self-review of my own code - [x] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [x] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#6-testing) for more details.
2025-05-09 19:41:31 +02:00
<input type="checkbox" id="preventModify" name="preventModify">
<label for="preventModify" th:text="#{permissions.selectText.7}"></label>
</div>
<div class="form-check ms-3">
Refactor permission variable names (#3457) ## Refactor: Improve clarity of permission variable names Renamed confusing `can[Action]` boolean variables to `prevent[Action]` (e.g., `canPrint` -> `preventPrinting`) in `PasswordController.java`, `AddPasswordRequest.java`, and `add-password.html`. The previous `can[Action]` convention was misleading, as `true` meant the action was *disallowed*. The new `prevent[Action]` naming directly reflects the intent (`true` = prevented), improving code clarity. **Changes:** * Updated variable names in controller logic * Updated `@Schema` descriptions in `AddPasswordRequest.java` * Updated corresponding HTML element attributes (`id`, `name`, `for`) in `add-password.html` **Important Notes:** * The underlying logic still inverts the boolean when setting permissions (e.g., `AccessPermission.setCanPrint(!preventPrinting)`). * User-facing UI text remains unchanged per request of @Frooodle in #3420. **Why not invert the API logic** * Inverting API (to can[action] logic) would either invalidate the UI * Inverting API AND changing UI would warrant bigger translation effort to change it in all languages * This version is consistent (meaning what the UI says is actually done) and preserve the UI language (meaning no translations needed) however it is inconsistent with PDFBox methods naming scheme **PDFBox** * **PDFBox Interaction:** This refactor addresses the naming *within* Stirling-PDF's API and Front-end layers only. The controller logic intentionally inverts the `prevent[Action]` boolean (`ap.setCanPrint(!preventPrinting)`) to correctly interact with the underlying PDFBox methods. No further renaming related to these permissions is necessary as the PDFBox methods themselves retain the `can[Action]` names. Underlying logic is not changed so it should work but just in case I tested locally on an Adobe PDF that contained form in Chrome. ## New variable names in API ![new API variable names](https://github.com/user-attachments/assets/f3d56aaf-0455-4f65-af14-c1a07a02d11a) **Related Issues:** Closes #3427 Closes #3420 --- ## Checklist ### General - [x] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [x] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md) (if applicable) - [x] I have performed a self-review of my own code - [x] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [x] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#6-testing) for more details.
2025-05-09 19:41:31 +02:00
<input type="checkbox" id="preventModifyAnnotations" name="preventModifyAnnotations">
<label for="preventModifyAnnotations" th:text="#{permissions.selectText.8}"></label>
</div>
<div class="form-check ms-3">
Refactor permission variable names (#3457) ## Refactor: Improve clarity of permission variable names Renamed confusing `can[Action]` boolean variables to `prevent[Action]` (e.g., `canPrint` -> `preventPrinting`) in `PasswordController.java`, `AddPasswordRequest.java`, and `add-password.html`. The previous `can[Action]` convention was misleading, as `true` meant the action was *disallowed*. The new `prevent[Action]` naming directly reflects the intent (`true` = prevented), improving code clarity. **Changes:** * Updated variable names in controller logic * Updated `@Schema` descriptions in `AddPasswordRequest.java` * Updated corresponding HTML element attributes (`id`, `name`, `for`) in `add-password.html` **Important Notes:** * The underlying logic still inverts the boolean when setting permissions (e.g., `AccessPermission.setCanPrint(!preventPrinting)`). * User-facing UI text remains unchanged per request of @Frooodle in #3420. **Why not invert the API logic** * Inverting API (to can[action] logic) would either invalidate the UI * Inverting API AND changing UI would warrant bigger translation effort to change it in all languages * This version is consistent (meaning what the UI says is actually done) and preserve the UI language (meaning no translations needed) however it is inconsistent with PDFBox methods naming scheme **PDFBox** * **PDFBox Interaction:** This refactor addresses the naming *within* Stirling-PDF's API and Front-end layers only. The controller logic intentionally inverts the `prevent[Action]` boolean (`ap.setCanPrint(!preventPrinting)`) to correctly interact with the underlying PDFBox methods. No further renaming related to these permissions is necessary as the PDFBox methods themselves retain the `can[Action]` names. Underlying logic is not changed so it should work but just in case I tested locally on an Adobe PDF that contained form in Chrome. ## New variable names in API ![new API variable names](https://github.com/user-attachments/assets/f3d56aaf-0455-4f65-af14-c1a07a02d11a) **Related Issues:** Closes #3427 Closes #3420 --- ## Checklist ### General - [x] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [x] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md) (if applicable) - [x] I have performed a self-review of my own code - [x] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [x] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#6-testing) for more details.
2025-05-09 19:41:31 +02:00
<input type="checkbox" id="preventPrinting" name="preventPrinting">
<label for="preventPrinting" th:text="#{permissions.selectText.9}"></label>
</div>
<div class="form-check ms-3">
Refactor permission variable names (#3457) ## Refactor: Improve clarity of permission variable names Renamed confusing `can[Action]` boolean variables to `prevent[Action]` (e.g., `canPrint` -> `preventPrinting`) in `PasswordController.java`, `AddPasswordRequest.java`, and `add-password.html`. The previous `can[Action]` convention was misleading, as `true` meant the action was *disallowed*. The new `prevent[Action]` naming directly reflects the intent (`true` = prevented), improving code clarity. **Changes:** * Updated variable names in controller logic * Updated `@Schema` descriptions in `AddPasswordRequest.java` * Updated corresponding HTML element attributes (`id`, `name`, `for`) in `add-password.html` **Important Notes:** * The underlying logic still inverts the boolean when setting permissions (e.g., `AccessPermission.setCanPrint(!preventPrinting)`). * User-facing UI text remains unchanged per request of @Frooodle in #3420. **Why not invert the API logic** * Inverting API (to can[action] logic) would either invalidate the UI * Inverting API AND changing UI would warrant bigger translation effort to change it in all languages * This version is consistent (meaning what the UI says is actually done) and preserve the UI language (meaning no translations needed) however it is inconsistent with PDFBox methods naming scheme **PDFBox** * **PDFBox Interaction:** This refactor addresses the naming *within* Stirling-PDF's API and Front-end layers only. The controller logic intentionally inverts the `prevent[Action]` boolean (`ap.setCanPrint(!preventPrinting)`) to correctly interact with the underlying PDFBox methods. No further renaming related to these permissions is necessary as the PDFBox methods themselves retain the `can[Action]` names. Underlying logic is not changed so it should work but just in case I tested locally on an Adobe PDF that contained form in Chrome. ## New variable names in API ![new API variable names](https://github.com/user-attachments/assets/f3d56aaf-0455-4f65-af14-c1a07a02d11a) **Related Issues:** Closes #3427 Closes #3420 --- ## Checklist ### General - [x] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [x] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md) (if applicable) - [x] I have performed a self-review of my own code - [x] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [x] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#6-testing) for more details.
2025-05-09 19:41:31 +02:00
<input type="checkbox" id="preventPrintingFaithful" name="preventPrintingFaithful">
<label for="preventPrintingFaithful" th:text="#{permissions.selectText.10}"></label>
</div>
</div>
<br>
<div class="mb-3 text-left">
<button type="submit" id="submitBtn" class="btn btn-primary" th:text="#{permissions.submit}"></button>
</div>
</form>
</div>
</div>
</div>
</div>
<th:block th:insert="~{fragments/footer.html :: footer}"></th:block>
</div>
</body>
</html>