Copying and renaming a share will not encrypt it anyway. It will get
encrypted when the owner’s files get encrypted.
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
The button group generated in email templates is expected to show the
two buttons side by side in a single row, but in Outlook both buttons
took the full width of the wrapper row and each button was shown in
its own row. To solve that the buttons are wrapped in an additional
table that shows each button in its own cell, limiting their width and
showing them in a single row; this is done conditionally and only
applied in Outlook, so it should not affect other clients.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
We hide **if** there is **no** notification.
We *do not* hide and *show the label* **if** there are notifications for
that application.
Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
For the overall OPcache size check, we currently compare used memory with free memory. However, `opcache.memory_consumption` is split into `used_memory`, `free_memory` and `wasted_memory`. When cached files change on disk, old entries are not replaced or removed, but remain as wasted memory, until the cache is actually full, and if their percentage is above `opcache.max_wasted_percentage`, which is 5% by default. When this happens, the engine is restarted, resetting the cache completely, like a `opcache_reset()` call.
As long as we do not consider wasted cache, recommendations based on free memory can be false. To solve this, we could count wasted memory as free memory, if it is above `opcache.max_wasted_percentage`, as the engine will be restarted as soon as needed, freeing up this wasted space. On the other hand, wasted memory below the threshold permanently blocks the OPcache, which supports counting it as used memory. Depending on the situation, instead of raising OPcache size, it could be also advised to reduce `opcache.max_wasted_percentage`. But too frequent cache resets break its purpose as well.
In my opinion, the matter is too complex to consider wasted cache correctly, and do precise recommendations, but we should focus on reducing false positives instead. What we know for sure is: if the cache is full (`$status['cache_full'] === true`), and the limit for cached keys has not been reached, the OPcache was too small to maintain free space, with wasted memory below the configured threshold, where it consumes memory permanently. Recommending to raise the OPcache size in this case, is hence as accurate as it gets. Even if 5% wasted cache could be freed, 95% used memory is still above the previous threshold for the setup check warning. And if `opcache.max_wasted_percentage` is above 5%, then the admin must have decided to change the default, deciding that system memory consumption has lower priority than preventing OPcache engine restarts.
`cache_full` can be true as well if the limit for cached keys has been reached, hence we need to merge both checks. In this case `num_cached_keys` equals `max_cached_keys` exactly, hence it is easy to differentiale whether `opcache.max_accelerated_files` or `opcache.memory_consumption` needs to be raised to address the `cache_full` state.
In practice, this change relaxes the checks: the respective limit needs to be reached 100% instead of 90%, to trigger a warning, eliminating also false alarms if a large share of the cache is consumed by wasted memory, which would be automatically freed once cache is 100% full.
Additionally, the recommendation for raising `opcache.max_accelerated_files` now says "a value higher than `max_cached_keys`", instead of "higher than `opcache.max_accelerated_files`". The actual limit, reflected by `max_cached_keys` from `opcache_get_status()`, [is a next higher value from a set of prime numbers](https://www.php.net/manual/en/opcache.configuration.php#ini.opcache.max-accelerated-files). E.g. if `opcache.max_accelerated_files` is set to 10,000 (PHP default), the effective limit is 16,229 OPcache keys. Recommending "higher than 10000" could hence lead to a settings change without effect. For an effective change, the new value needs to be "higher than 16229" instead, which is what the setup check will show in this situation, with this change applied.
Signed-off-by: MichaIng <micha@dietpi.com>
The password confirmation dialog is always shown unless the user backend
does not allow password confirmation. A user backend may explicitly
provide that information, but even if it does not that could have been
defined in the authentication token with
"IToken::SCOPE_SKIP_PASSWORD_VALIDATION" (for example, when "user_oidc"
is only used for authentication and user provision is done by another
user backend).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the toast shown while a file is being moved or copied was
introduced in 64cc7afb12 an additional condition was added to the
"isLoading" check of file entries. However, that additional condition
caused an endless loading spinner to be shown on file entries of the
"Shares" view (but not in other views) after an action was triggered.
Turns out that the condition was not actually needed for the toast, so
now it is removed again to solve the endless loading spinner.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Côme Chilliet
Daniel
Nextcloud bot
Christoph Wurst
Daniel Calviño Sánchez
Joas Schilling
nextcloud-command
Git'Fellow
John Molakvoæ
Ferdinand Thiessen
skjnldsv
Kate
Anna Larch
Joas Schilling
Robin Appelman
MichaIng
Josh
SebastianKrupinski
Jyrki Gadinger
Côme Chilliet