Commit graph

1375 commits

Author SHA1 Message Date
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
Pere Lev
789411f5d2
S2S: Project: Grant: Before extending a Grant, test to avoid infinite loop 2024-04-14 03:04:05 +03:00
Pere Lev
6dd6dc17e5
S2S: Enforce max chain length when verifying OCAPs 2024-04-13 17:00:44 +03:00
Pere Lev
692c34bdec
S2S: Project: Grant: When getting a new parent, send them a start-Grant
This was accidentally not happening until now.

If I, project A, send a start-Grant to my new parent project B, it means
that whoever has access to project B will have access to my settings as
well (for the specific operations their role allows).
2024-04-13 16:05:37 +03:00
Pere Lev
dae57c394d
UI: Personal Overview: Display info of received permits, not just the Grant URI 2024-04-13 15:34:26 +03:00
Pere Lev
68a3fcd7c8
S2S: Fix bug, CSRF check was accidentally enabled for ProjectInboxR 2024-04-12 21:24:47 +03:00
Pere Lev
1abbfdaa35
README: Mention NLNet funding 2024-04-11 16:17:54 +03:00
Pere Lev
719999242a
S2S: Project: Grant: Fix capability check, do it in MaybeT, not ExceptT 2024-04-10 22:37:12 +03:00
Pere Lev
f326b276c2
UI: Project: Parents: Fix table header 2024-04-10 21:56:11 +03:00
Pere Lev
f54caef7ca
S2S: Project: Fix search of activities in DB 2024-04-10 20:09:23 +03:00
Pere Lev
0b08a7692a
UI: Browse: List project's enabled children 2024-04-10 17:27:40 +03:00
Pere Lev
24aba4d370
S2S: Project: Revoke: Handle child revoking one of the Grants they sent me 2024-04-10 16:27:29 +03:00
Pere Lev
a16fb6cd19
S2S: Project: Revoke: Handle parent revoking the delegator-Grant 2024-04-10 11:25:15 +03:00
Pere Lev
223fbf3d0e
S2S: Project: Accept: Implement remove-child mode 2024-04-04 15:33:09 +03:00
Pere Lev
bf8ae421ff
S2S: Project: Accept: Split the different modes into separate functions 2024-04-04 13:03:48 +03:00
Pere Lev
048c429def
S2S: Project: Remove: Implement child/parent mode 2024-04-04 11:54:13 +03:00
Pere Lev
7a0ea1f63d
S2S: Project: Remove: Switch to full OCAP verification 2024-03-28 11:26:34 +02:00