BUGFIX: Invalidate triple was not being written to the correct graph

[lagartoverde]

No description provided.

[abeforgit]

shouldn't this be written to both graphs? @nvdk can you check this? I don't know enough about sudo services and mu-auth to review this

[lagartoverde]

shouldn't this be written to both graphs? @nvdk can you check this? I don't know enough about sudo services and mu-auth to review this

Mmmmm, technically not because we don't use the valid through inside the app, only from outside, but I don't know if it's semantically more correct

[nvdk]

afaik published templates (or rather their metadata) is only written to the published graph. Let me just describe what I think should happen in this service:

1. when publishing a template, we create some metadata in the public graph that describes the published template
   This means the public graph has at least a publisher, a title a date created and a pointer to where to download the template. Ideally (though I understand that's not the case yet) that means the file description is also part of the public graph
2. when unpublishing a template we set a valid until date on the template

So from that standpoint this seems correct.

I do have some questions on how that relates to the data from the app users standpoint. note that there's a disconnect between the public data above and the actual documents that a user maintains. The idea is that the publication creates a separate public file (on disk or in the db) that contains a published variant. In the app itself it may or may not be possible to delete documents. I don't think the publishing service should take care of that.

[abeforgit]

afaict the user (that is, the person logged in to the registry) only sees the templates. Every template can be in 2 states, not published or published. When you make a change to a published template, the currently published version gets overwritten (from the user's standpoint, no idea what the data does)
Now the user has the option to delete a template. That deletes it from the registry (via mu-cl-resources, not sure from which graph it gets deleted?), and also sets the invalidation date, via this service.

[lagartoverde]

Basically we have 2 data structures:

• Reglement: It has a document container via ext:hasDocumentContainer this document container behaves the same as GN, with the different versions etc...
• ext:PublishedRegulatoryAttachmentContainer: This is the publication container, is linked to the reglement via ext:publishedVersion, it has a current version of ext:PublishedRegulatoryAttachment, also a version history with pav:previousVersion which is currently not used for anything.

[nvdk]

Sideremark: For public data we should avoid using the ext namespace

On 4 October 2022 13:57:16 CEST, Oscar Rodriguez Villalobos ***@***.***> wrote: Basically we have 2 data structures: - Reglement: It has a document container via `ext:hasDocumentContainer` this document container behaves the same as GN, with the different versions etc... - ext:PublishedRegulatoryAttachmentContainer: This is the publication container, is linked to the reglement via `ext:publishedVersion`, it has a current version of `ext:PublishedRegulatoryAttachment`, also a version history with `pav:previousVersion` which is currently not used for anything. -- Reply to this email directly or view it on GitHub: #5 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[abeforgit]

Well the discussion has no conclusion but I guess its fine to merge