Store restrictions instead of capabilities in Files App |
||
Issue descriptionSince most files have full read-write access, it may simplify the logic (and perhaps save memory) to only store capabilities for entries whose values differ from the defaults. This means, instead of storing: canCopy canDelete canRename canAddChildren canShare for every entry, just store: copyRestricted deleteRestricted renameRestricted addChildrenRestricted shareRestricted for entries that have these accesses restricted (Naming TBD). Also, to further save memory, this could be represented as an array, or set of flags.
,
Jun 6 2018
Makes sense to me.
,
Jun 6 2018
Ahh damn I was so close to getting bug number 85000.... ;)
,
Jun 6 2018
Sorry, did I say 85000? I meant 850000 D: (see issue 850000 )
,
Jun 6 2018
(I wonder who has issue 888888 )
,
Jun 13 2018
While fixing this, we should also fix the "undefined" problem. Currently, some entries retreived from the cache can have canCopy (for example) set to undefined. For example: * If the metadata is not fetched from the server yet * If there is a problem with the cache and we don't have the data for canCopy We should fix the API and the metadata provider to set these to a default value (e.g. true) so that the UI doesn't have to.
,
Jun 13 2018
To append to above: this would clean up checks like "metadata.all(item => item.canCopy !== false)" (since it can be true or undefined, but not false).
,
Jul 24
|
||
►
Sign in to add a comment |
||
Comment 1 by sashab@chromium.org
, Jun 6 2018