- finds resources & displays details using metadata-store
- supports creating new collections for groups
- supports creating new collections with new unmanaged group
- supports receiving invites for new (unmanaged) collections
In order to track & respond to all group-related metadata, hooks may
want to subscribe to the metadata-store in response to group creation.
In that case it is possible that there are no entries for the group-path
in group-indices yet.
This makes us fall back to the empty set in case group-indices has no
entry for the group-path yet.
The previous Tile.png for the Dojo module (Soto) was a stylized rendering of "barcen" and could be seen as confusing. Fixing up the image to appear more *actually* glyph-like.
In order to track & respond to all app-related metadata, hooks may want to
subscribe to the metadata-store as the first thing they do on-init. In that case
it is exceedingly likely that there are no entries for the app-name in
app-indices yet.
This makes us fall back to the empty set in case app-indices has no entry for
the app-name yet.
Basically, this PR includes a collection of edits made to the headers across each of our OS1 modules.
I flattened the font sizing, fixed edge margins/padding, and fixed some button copy in the case of the Contacts app.
If we don't host a group, we can't (locally) delete it, but we do still
have a permission-hook entry we want to clean up. This does that
deletion, but still relies on the permission-hook logic to clean it up
in the local group case.
Permissions for the new group need to be exposed to the members of those
new groups. This makes the on-migrate logic poke the permission-hook for
that.
This temporary, upgrade-oriented logic depends on two assumptions:
- If the metadata-store is not running, we are still in the process of
applying the upgrade.
- If the above is true, all chats are /~host/name, all groups are
/~/~host/name, and they have a strict one-to-one relation.
Armed with those assumptions, we can deduce groups from chats and vice
versa without depending on the metadata-store, allowing us to carry on
as if it were already running.
If we %add-owned, then we add an entry to the access-control jug matching the
data we put into the synced map. When a permission gets deleted, we remove it
from synced, but previously neglected to clean up the matching access-control
entry.
This ensures that if a permission was deleted, and we had it registered as
owned, that the relevant access-control entry is removed from state.
