AshArchival
Dear team,
I am currently trying to implement AshArchival.
In order to be able to read the archived and none archived value. the documentation says I need to create a separate resource.
Shall this separate resource have everything same as the original one, except it does not have the 'extensions: [AshArchival.Resource]' and instead have the
Should I also duplicate all the policies, calculation etc... too ?
Regards,
Angy.
16 Replies
To add to my previous post : should ai only duplicate the attributes and that is all ?
You shouldn't have to create a separate resource for the archived items.
Then set up your policies to allow some user groups to read_archived, read_all, and unarchive.
The base filter means the default read will always filter out archived records
The archive block specifies which actions are excluded from the base filter.
I forgot why I have base_filter_sql in the postgres block and base_filter in the resource block. Did it awhile back, but seems to work ok.
But, it all depends on how you want to model your domain. If you want to have a Foo resource and an ArchivedFoo resource pointing to the same table with different base filters, that works too
Sometimes it is helpful to break them apart, but for my use case I didn't
How, thanks. I will try to implement it π and will let you know my progress π
Are you sure that works? I didn't think the base filter was compatible with the exclude read actions option
I think you have to do it without the base filter?
Iβd have to ask Rebecca since she fought with the archival stuff for a while on my app. Pretty sure your only need to do the archival block base filter. Iβll check with her when she some online and post the answer here.
I don't know of a way to bypass the base filter on a resource is all π
@sevenseacat Any idea why we put both
base_filter_sql
in the postgres block and base_filter
in the archive block on the Contact resource? I provided an example for this support item and Zach thinks that combo shouldn't work. You wrestled with it for awhile and settled on having both.Hi @Chaz Watkins, I have tried in my test both:
and both return
if you don't use the base filter option, then archival is done with a filter on all read actions
so when you exclude actions, you can then read archived items using that action
AFAIK this is explained in the ash archival docs
@Zach Daniel
I have made it work locally with configuration similar to:
So, I am happy this work but I had to remove the
and keep the
to make it work. Do you know why I needed to remove the ?
Also, I think this could be a good idea to update the documentation as it is not needed to create separate ressource and this example in the code is simpler to use I think.
Also, it is working well with PaperTrail. Do you want me to share the code for it... as an example ?
A PR to the docs would be great π I'm confused that you had to keep
base_filter_sql
, that doesn't make much sense π€
since you removed the base_filter
itself that shouldn't be necessaryI donβt think I tested it with the exclude_read stuff, because it wasnβt used anywhere
gotcha. So, Zach's probably right. You only need base_filter in the archive block
after removing the
I have got the following warning
Could this explain why we need to keep it ?
I cn do that, yes π once I have finished my PR in my project π
base_filter_sql "(archived_at IS NULL)"That should only be required if you also have a base filter but with
base_filter? false
and no base_filter ...
setup, you shouldn't need thatworking well π thanks