however, the feature will mainly focus on purging docs while the docs owner (user) leaves the channel of the docs belong to.
I have the following scenarios observed in 2.8 (as well as 2.8.x) need to be also covered by Lithium channel access improvement:
create a doc on CBL with channels, replicate (continuous=true) the doc to SGW, on CBL remove all channels the doc was assigned, the doc gets auto purged on CBL (currently the doc stay with empty channel data)
create a doc on CBL with channels, replicate (continuous=true) the doc to SGW, on SGW remove all channels the doc was assigned, the doc gets auto purged on CBL (currently docs stay with empty channel data)
create a doc on SGW with channels, replicate (continuous=true) the doc to CBL, on SGW remove all channels the doc was assigned, the doc gets auto purged on CBL (currently it works expected)
create a doc on SGW with channels, replicate (continuous=true) the doc to CBL, on CBL remove all channels the doc was assigned, the doc gets auto purged on CBL (currently docs stay with empty channel data)
Discussed my observations with and , will confirm if a CBL doc with empty channel should be purged or not.
will change the status to resolved, then close it after it gets verified.
Pasin Suriyentrakorn June 10, 2021 at 9:20 PM
This is fixed with the code that handles revoked / removed revisions when using the BLIP_V3 protocol (CBL 3.0 and SG 3.0).
Adam Fraser April 30, 2021 at 8:37 PM
The deleted flag is only used to indicate tombstones, and will continue to only be used in that way. The existing removed:true flag will continue to be used when a new revision of a document leaves a channel being replicated. The new revoked:true flag will be used to notify a client that it's lost access to an existing revision.
I think it's useful to continue think about these as three separate flags, even if the transport layer is sending these as a single bitfield property (which I believe is what you're talking about when you say the deleted property will be set).
Fixed
Pinned fields
Click on the next to a field label to start pinning.
Lithium has a feature of handling revocation of channel access:
https://docs.google.com/document/d/14gawyt9lcHYUlCh0APUt-7V6M6Kkk0zoXi7GOfYiMLM/edit#heading=h.8yekawi4x61d
however, the feature will mainly focus on purging docs while the docs owner (user) leaves the channel of the docs belong to.
I have the following scenarios observed in 2.8 (as well as 2.8.x) need to be also covered by Lithium channel access improvement:
create a doc on CBL with channels, replicate (continuous=true) the doc to SGW, on CBL remove all channels the doc was assigned, the doc gets auto purged on CBL (currently the doc stay with empty channel data)
create a doc on CBL with channels, replicate (continuous=true) the doc to SGW, on SGW remove all channels the doc was assigned, the doc gets auto purged on CBL (currently docs stay with empty channel data)
create a doc on SGW with channels, replicate (continuous=true) the doc to CBL, on SGW remove all channels the doc was assigned, the doc gets auto purged on CBL (currently it works expected)
create a doc on SGW with channels, replicate (continuous=true) the doc to CBL, on CBL remove all channels the doc was assigned, the doc gets auto purged on CBL (currently docs stay with empty channel data)
Discussed my observations with and , will confirm if a CBL doc with empty channel should be purged or not.