Related Files
#1290
Replies: 4 comments 3 replies
-
Reserved for Updates. |
Beta Was this translation helpful? Give feedback.
3 replies
-
Thread for comments on the initial mockup for Related Files: File Categories Relationships |
Beta Was this translation helpful? Give feedback.
0 replies
-
Thread for comments on the initial mockup for Split Files. |
Beta Was this translation helpful? Give feedback.
0 replies
-
Thread for comments on the initial mockup for Related Folders. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Goal
The goal is to allow apps to request access to additional files or folders with the same name as a first open file or folder, limited to the relevant file or folder categories. These extra files or folders are part of a relationship between file categories (e.g. video->subtitles), a split file category (e.g. split archive), a relationship between a file and one or several folders (e.g. a project file with a folder for data), or a relationship between folders (e.g. a main project folder with a folder for data and for build).
Requirements
App Developers
Portal
Database of Categories
Related Files Rules
Split File Category
Split file extensions usually contain at least one letter and varying digits.
In the reference file, the split file category is written with its label followed by types (extensions) where each letter of the entire extension is written, and each digit is replaced, for example, with an asterisk ("*").
The rules to respect are:
Here is an example with RAR split archives divided into parts r01, r02, etc. and into parts part01, part02, etc., and with 7z split archives divided into part 7z.001, 7z.002, etc.:
Relationship Between File Categories
The relationships between file categories are written using their labels in the database, then the relevant types supported by the app are written for each category separated by a semicolon (;). The first category of the relationship is the one that "wants" access to the files of the second category (i.e. the related files). Multiple second categories can be written, separated by a semicolon.
The rules to respect are as follows:
Example:
Relationship With Related Folders
This concerns the relationships between a file or folder category and one or several folder categories. The first category of the relationship is the one that "triggers" the access to the second categories. Categories are written using their labels in the database.
The rules are as follows:
Example:
Validation of Split File Categories and of Relationships
There are two options to validate split file categories and relationships defined in the app reference file, one of which needs to be chosen for the development of this portal:
Validation When Installing the App
When an app is installed, the validation program checks whether it supports related files. If this is the case, it checks the defined categories and relationships with the help of the database and related files rules.
When the validation has been performed, the program stores the following information in the permission store:
Finally, the validation program sets permissions to "none" for split file categories and for all relationship categories.
Validation When Updating the App
When the app is updated, the program performs validation using the related files rules and the database, takes the difference between this validation and the one stored in the permission store, and does the following in the permission store:
And so on.
Functioning
Note: The following text is for understanding purposes only. Things can be done differently if wanted; only the end results are important.
Checking Tags and Permissions Before App Startup to Manage Changes
When the app is launched, but before it starts, the portal checks the permission store for the presence of "removed" tags, "new" tags, and categories with permissions set to "new". If there are items that have both the "removed" tag and a permission set to "none", the portal deletes them from the permission store.
Next, it displays a window showing the remaining types and categories that have a "removed" tag, as well as those with a "new" tag and a "new" permission. The portal communicates which ones have been removed and which ones are new. For ease of reading, the types are categorized by split file categories and file categories; file and folder categories are ordered such that the second categories appear under the first category with which they have a relationship (for example, "Subtitles" and "Audio" under "Video", "Materials" under "Inform"). If a second category has a relationship with several first categories, these appear under their first categories mentioned together (for example "Subtitles" under "Video, Audio").
The portal also communicates that permissions must be set again for split categories and relationships that have not been removed, that already have a permission that is not "none", and that have removed and/or new items (including categories with permission set to "new").
When the user has confirmed that they has read the text, it displays a window to set permissions for split file categories and relationships, including their categories, that have not been removed, that have their permissions not set to "none" (including categories having permission set to "new") and which have removed and/or new types. Removed items are not shown because no permissions need to be set for them. When the user has set all permissions, the portal stores them in the permission store and removes all "new" tags (only tags) and all remaining types and categories that have a "removed" tag.
Initial Checks and Behaviors
Here are the checks and their values, with the necessary information retrieved from the permission store:
To begin, the user selects a file or folder to open via the file chooser or file manager; the file or folder is not returned to the app. Then the portal performs check (1). If the value of check (1) is "none", then the portal returns only the user-selected file or folder to the app. If check (1) has the value "same-category", then the portal uses the method for neighboring files of the same category (see the proposal "Neighboring Files: Neighbors Of The Same File Category"). If it has the value "related-files", the portal continues with check (2). If there are both "same-category" and "related files" values, the portal uses the "same-category" method first, then uses the method for related files when "same-category" has been applied.
When check (2) has been performed, the portal has one of the following behaviors depending on the resulting value of check (2):
Checks and Behaviors for a Split File Category
Checks and their values, with the necessary information retrieved from the permission store:
If (S1a) has the value "no", then the portal performs check (S1b). However, if the value is "yes", then it does check (S2). If check (S1b) has the value "no", the portal returns to the app only the file selected by the user. If check (S1b) has the value "yes", it performs check (S2).
When check (S2) has been performed, the portal has one of the following behaviors depending on the resulting value:
Checks and Behaviors for Related Files or Folders
Checks and their values, with the necessary information retrieved from the permission store:
When the portal has retrieved the categories and their tags by performing check (F1), the portal continues with check (F2).
When check (F2) has been performed, the portal has one of the following behaviors depending on the value obtained:
Removal of Access to Related Files/Folders
Once the app is no longer running, the portal removes access to associated files or folders. This automatic removal of file and folder permissions avoids doing so when the access permission is reset to "none", set to "manual" after being set to another value, or when a category has been removed. This also prevents the app from acquiring many files or folders over time, especially if the app's static permissions change from something good to something bad, at least if the app has not not copied the files.
Methods for File Categories
Search Locations Method
The "search-locations" method allows an application to call a window presenting a user interface for adding and removing folders in which the portal can search for related files.
This method is only available for relationships between file categories. So when the app calls this method, the portal checks the permission store that (1) the app supports the associated files and (2) there is at least one relationship between file categories (i.e. that at least a first category and a second category relating to the first both have a "file" tag). If checks (1) and (2) are met, the portal displays the "search-locations" window.
In the interface, the user can add and remove folders only for relationships between file categories for which "automatic" permission has been set; if there is no "automatic" permission, a window appears stating that no folders can be added due to lack of permissions. A folder in which files cannot be read by the user cannot be added. Additionally, the user interface may have a button to access permission settings. It can be present in the UI and the interface is refreshed when permissions are changed. For convenience, when a permission is changed from "automatic" to "manual", folders that have been defined are not removed in case the permission is changed back to "automatic".
There are two signals: (1) "open" which signals that the "search-locations" window is open, and (2) "closed" which signals that the window has been closed. These signals allow, for example, a video player to pause a video when the window is open, and to replay the video when the window is closed. The "search-locations" window can be modal if wanted.
With the "search-locations" method, an app might infer that the user is probably adding and removing folders between the "open" and "closed" signals, the other possibility being that the user is doing something else. The app cannot know which folders have been added and deleted.
Search Related Method
The "search-related" method allows the app to ask the portal to search for related files from a file inside the sandbox (e.g. from a recent file or a file from an added folder). It is limited to relationships between file categories.
When calling this method, the app must send the document ID of the file. When the document ID is given, the portal checks the permission store that (1) the app supports related files and (2) there is at least one relationship between the file categories (i.e. that at least a first category and a second category relating to the first both have a "file" tag). If checks (1) and (2) are met, the portal performs the checks and behaviors from the "Initial Checks and Behaviors" section. In this specific case, if permission is set to "none", then it might be nice to show in the dialog asking for permission which file was used when the "search-related" method was called, while not forgetting that permission is requested for any file that will be opened. Showing the file that was used is useful so that the user can verify that the dialog box is displayed following one of their actions on the mentioned file.
There is the "done" signal which tells the app that all related files found have all been returned to it.
Folder Opening Limited to First File Categories of File Category Relationships
When opening a folder (including adding it as a library) is requested, via the file chooser, file manager or by drag and drop, checks are performed. The relevant portal checks the permission store to see if the app supports related files and neighboring files of the same category. If so, it scans whether all files in the folder (including of all subfolders, etc.) belong to valid first file categories of relationships between categories, and to valid categories and subcategories of neighboring files of the same category (if any). A dialog box displays the progress of the scan. Once the scan is complete and the file categories and file subcategories has been determined, the dialog box asks the user which categories they wants to import, allowing multiple ones to be imported. If the user chooses to import one or more categories, the portal returns only files from the selected ones to the app.
This is done because apps will be able to use both "same-category" and "related-files" methods, and adding a folder for related files, as a library or by restoring it, is not wanted as there is the "related-files" method for them. This is for example the case for videos: a video library can be added, but not a subtitle library because subtitles can be acquired using the "related-files" method.
If the app wants to access more file types than those defined for related files and for neighboring files of the same category (if any), then it must define them in the app reference file; file types of second file relationship categories of file and use of the wildcard "*" are not allowed.
However, the portal must communicate this to the user, so that they are aware of it. This must be communicated when setting permissions. Optionally, the user can be reminded of this in the file chooser.
Note: This limitation does not apply to relationships with a related folder or to split file categories.
Other Ideas
Filters in the File Chooser
All valid types in the permissions store are used as filters in the file chooser. There is a filter for each valid category. These filters are automatically added.
The file types accessible from the file chooser are only those for which a filter has been defined. So, If the app wants to access more file types than those defined for related files and for neighboring files of the same category (if any), then it must define them in the app reference file like for when opening a folder; file types of second file relationship categories of file and use of the wildcard "*" are not allowed.
Multiple Selection Limited To Supported File Categories
Same process as when opening a folder, but when the user selects multiple files in the file chooser or file manager. However, in this case, adding all categories is possible. This allows them to easily selects multiple files at once, without individually selecting or deselecting some of them. Note that if the app wants to access more file types than those defined for related files and for neighboring files of the same category (if any) like for when opening a folder, then it must define them in the app reference file; file types of second file relationship categories of file and use of the wildcard "*" are not allowed.
This must also be communicated to the user.
Notes
Related Folder Is Not Returned
If a related folder is not returned, tell this in the app using, for example, a banner with an "Open" button.
If the app wants to write files to a related folder that is not open, the app will have to ask to write files to that folder. Next, what we need to know is how to manage this writing. See #997.
Mockups
Questions
Beta Was this translation helpful? Give feedback.
All reactions