Pere Lev
d72e06727c
S2S: Group: Accept: Port child-parent modes from Project
2024-05-13 02:03:58 +03:00
Pere Lev
ee30cb9f70
S2S: Project: Accept: Separate child and parent modes' code
2024-05-13 01:08:47 +03:00
Pere Lev
3162a6ac28
S2S: Group: Implement Add handler based on Project
2024-05-12 22:24:07 +03:00
Pere Lev
bef8a77d84
UI: Browse: List team parents
2024-05-12 21:46:34 +03:00
Pere Lev
74af2ea223
UI: Group: Display parent and child invites & approve-remove buttons
2024-05-12 20:15:53 +03:00
Pere Lev
533fc60fe1
UI: Group: Implement parent/child process button POST handlers
2024-05-12 19:38:50 +03:00
Pere Lev
66c1818fcd
Client: Use the new Add-based version of adding a component
2024-05-12 18:11:17 +03:00
Pere Lev
f6dda396dd
S2S: Project: Add: Implement Add-based version of projectInvite
2024-05-12 17:50:18 +03:00
Pere Lev
f864274ff0
S2S: Component: Implement Add-based version of inviteComponent
2024-05-11 22:25:50 +03:00
Pere Lev
38ce72996c
Port deckAdd to be a reusable componentAdd
2024-05-05 23:38:58 +03:00
Pere Lev
4b6e95b2e8
DB: Remove StemIdent* tables, use Komponent instead
2024-04-30 00:32:30 +03:00
Pere Lev
5d594ca738
DB: Remove ComponentLocal* tables, use Komponent instead
2024-04-29 23:23:59 +03:00
Pere Lev
aeb1a83c93
DB: Add a Komponent record, to gather local repos/decks/looms/etc.
2024-04-29 14:38:37 +03:00
Pere Lev
1d08e43175
CSS: Tweak styling of buttons, fixing the clipped button bug
2024-04-29 13:41:51 +03:00
Pere Lev
42b83c11f9
UI: Deck: Projects: Button for removal
2024-04-29 13:26:15 +03:00
Pere Lev
9646b72ded
UI: Project: Components: Button for removal
2024-04-29 11:32:11 +03:00
Pere Lev
12ea0c021e
UI: Deck: Projects: More detailed table + button for approving
2024-04-29 11:01:33 +03:00
Pere Lev
ca6aa718f6
UI: Project: Components: More detailed table + button for approving
2024-04-29 09:58:04 +03:00
Pere Lev
ffe1c39fd3
UI: Deck: Form for adding to a project
2024-04-29 02:08:44 +03:00
Pere Lev
d04f161203
UI, Client: Move invite-component form to ProjectComponentsR and use getCapability
2024-04-29 01:14:56 +03:00
Pere Lev
6cdd332d1d
UI: Remote actor view + follow UI
2024-04-28 21:08:04 +03:00
Pere Lev
a428bd74ab
UI, S2S: Store errors in Errbox + display in notifications
2024-04-28 00:31:48 +03:00
Pere Lev
a60b05b1ca
UI: Error-inbox ("Errbox") display for all local actors
2024-04-27 23:17:22 +03:00
Pere Lev
29e7581b19
DB: Give each actor a secondary inbox, for collecting errors
2024-04-27 22:46:37 +03:00
Pere Lev
ef036fd08b
UI: Project: Parents: Button for approving a parent
2024-04-27 22:02:40 +03:00
Pere Lev
99f6d950a2
UI: Project: Parents: Form for adding a parent by URI
2024-04-27 21:46:49 +03:00
Pere Lev
082eae7a51
UI: Project: Children: Button for approving the Add
2024-04-27 21:37:13 +03:00
Pere Lev
d9d6b9fced
UI: Project: Children: Form for adding a child
2024-04-27 20:58:26 +03:00
Pere Lev
9e24038ec2
Deliver activities to remote audience before local+collections
...
This is an attempt to prevent remote activities from being received in
the wrong order, for example Accept coming before the Add. Whenever that
happens, the add-a-child-parent-link process cannot be completed.
If this doesn't help, another option is to store, per actor, a list of
activities that weren't used, and check them in relevant S2S handlers.
This might have an implication on forwarding if it's time limited (I
don't remember exactly). But worth trying. Example:
- I receive an Accept on an activity I don't recognize
- I store it in that list, for later
- Later I receive an Add activity, which I successfully process
- Now I check that Accept from earlier, seeing if its `object` happens
to be the Add I just received
- If yes, I now process this Accept
A potential problem with this, is that I might accumulate a list of such
activities, and end up hopelessly checking them in every S2S handler.
And I wonde if this is really a healthy elegant approach to the ordering
problem. Maybe some sort of activity numbering can help?
2024-04-27 20:13:01 +03:00
Pere Lev
b519bbe7b9
UI: Inbox: For each item, display the result of processing
2024-04-27 19:29:33 +03:00
Pere Lev
eef4c3f79a
S2S, DB: Store processing result in InboxItem record
2024-04-27 19:15:28 +03:00
Pere Lev
d24492bf44
S2S: Person: Revoke: Fix bug: Forgot to delete PermitExtendResource*
2024-04-27 13:20:06 +03:00
Pere Lev
476f65aece
S2S: Project: Remove: Child-active: Fig bug, forgot to remove SourceUsLeaf records
2024-04-27 12:40:29 +03:00
Pere Lev
c2da1da9f4
S2S: Project: Accept: Add-child-passive: Fix bug, no need to record the Accept in the Source
2024-04-27 12:25:13 +03:00
Pere Lev
bb1685f695
UI: Project: Buttons for removing parents
2024-04-27 11:31:09 +03:00
Pere Lev
c62c1674ee
Homepage: Mention funding, tweak wording, remove IRC channel link
2024-04-27 11:13:04 +03:00
Pere Lev
abefcbd310
UI: Project: Provide buttons for removing children
2024-04-27 10:56:11 +03:00
Pere Lev
07d9f9adab
UI: In my-grants-for-given-resource display, list direct grants as well
...
Previously, only extensions were being displayed. Adding direct grants
required DB schema changes, which the previous huge commit did.
2024-04-26 03:00:59 +03:00
Pere Lev
888a30e989
DB: Switch Collab and Permit to use Resource
...
Since collaborator live URIs were using CollabTopic*, this change breaks
existing live URIs, which means all existing delegation chains are now
broken. FYI if you're playing with your own Vervis deployment.
2024-04-26 02:00:41 +03:00
Pere Lev
4881154579
DB: Permit: Use Resource instead of Actor in extension resource
2024-04-20 04:15:59 +03:00
Pere Lev
acdce58fc6
DB: Add a Resource table, and use it in all local Actors except Person
2024-04-20 03:52:34 +03:00
Pere Lev
fc9d56dd34
UI: When logged in, display my delegated access to a given local resource
...
This displays only delegated Grants, not direct ones. Direct ones will
be added in the next commits, as they require some extra changes in the
database.
2024-04-20 01:59:13 +03:00
Pere Lev
4fe3f9f332
On launch, fetch actors and fill PermitTopicExtendResource records
2024-04-19 03:22:20 +03:00
Pere Lev
ab08e593ef
S2S: Person: Grant: Record role and resource in Permit record
2024-04-19 02:30:33 +03:00
Pere Lev
1f36657084
UI: Removal form: Extend to work on children/parents as well
2024-04-18 22:52:26 +03:00
Pere Lev
7dcb225aa8
HTTP inbox POST delivery: Don't retry on 4xx responses
2024-04-14 20:32:53 +03:00
Pere Lev
8024e993a2
DB: Simplify ComponentGather using the new DestUsStart
2024-04-14 15:21:56 +03:00
Pere Lev
b47941af97
DB: Split migration model module + remove DestUsGatherTo* entities
2024-04-14 15:06:50 +03:00
Pere Lev
97b675130f
Switch to DestUsStart in parent/child Live routes
...
This breaks the old Live routes, so existing chains will stop working
2024-04-14 13:52:35 +03:00
Pere Lev
8f6f5d61bf
S2S: OCAP verification: Support detection of DestUsStart start-Grants
...
Until now, a start-Grant could be only a Collab (if it's stand-alone) or
a Stem (if it starts a chain). In other words, either a resource
enabling a direct collaborator, or a component enabling a project that
contains it.
With the new project nesting feature now implemented, there's a new kind
of start-Grant: A child project, once enabled by its parent, sending the
first delegation, giving access-to-self.
2024-04-14 12:49:42 +03:00
