Extract acitivities into a separate plugin#6790
Conversation
de37100 to
09ece3f
Compare
There was a problem hiding this comment.
Had a first quick look and overall it looks good, see some questions and comments @smotornyuk
My main concerns are compatibility, making the transition transparent for most users, specially regarding URLs.
For those wanting to have a look check the changes in the logic folder, specially where the new action_succeededsignal is fired, and the subscriptions file where the activity plugin registers its listeners
| 'activity_type': 'new user', | ||
| } | ||
| logic.get_action('activity_create')(activity_create_context, activity_dict) | ||
| # session.flush() |
There was a problem hiding this comment.
Let's remove this and the comment above is no longer required
| @@ -0,0 +1,5 @@ | |||
| Activites extracted into `activity` plugin: | |||
There was a problem hiding this comment.
We should make clear that users should add the activity plugin to their ckan.plugins config option if they want to keep seeing the activities!
There was a problem hiding this comment.
Also I think this plugin should be added by default when creating a new ini file (can we add a default for ckan.plugins like we use to do adding stuff to deployment.ini_tmpl?
There was a problem hiding this comment.
i agree about adding as default to ckan.plugins
There was a problem hiding this comment.
Yep, changelog record updated and activity added to the list of plugins inside the generated config file
| return base.render(u'user/dashboard_groups.html', extra_vars) | ||
|
|
||
|
|
||
| dashboard.add_url_rule( |
There was a problem hiding this comment.
Will url_for('dashboard.index') still work? Otherwise is a pain in the ass for extensions
There was a problem hiding this comment.
Yes, it works but produces the following log record:
2022-05-15 18:40:30,579 INFO [ckan.lib.helpers] Route name "dashboard.index" is deprecated and will be removed. Please update calls to use "activity.dashboard" instead
| activity = Activity.activity_stream_item(pkg, type_, user_id) | ||
| context["session"].add(activity) | ||
| context["session"].commit() |
There was a problem hiding this comment.
Why aren't the dataset activities created via the activity_create action like the group or user ones?
There was a problem hiding this comment.
activity_create action requires an existing user ID. Such code bypasses this restriction. If you check a few lines above, you'll see user_id = 'not logged in' line, which allows changing a package anonymously(via ignore_auth I suppose).
Even though it looks like a really bad idea, we cannot just require an existing user here. I definitely have seen not logged in in the activity streams, which means that such a change can potentially break existing workflows.
So it's one of those "bugs and problems" that I noticed and decided to keep in order to avoid behavioral changes as much as possible.
|
|
||
| g.pkg_dict = pkg_dict | ||
| g.pkg = pkg | ||
| # NB templates should not use g.pkg, because it takes no account of |
There was a problem hiding this comment.
IIUC We are changing the URL here right? so on CKAN < 2.10 it would be:
/dataset/my-dataset?activity_id=<activity_id>
And going forward it will be:
/dataset/my-dataset/archive/<activity_id>
Can we keep a small compatibility check to not break URLs? Something like:
if p.plugin_loaded("activity"):
activity_id = request.args.get("activity_id")
if activity_id:
return redirect("activity.package_archive", id=pkg_id, activity_id=activity_id)WDYT?
(also see note about the name "archive" below)
There was a problem hiding this comment.
makes perfect sense. I wanted to handle this case, but I just hadn't come to such an obvious solution 😆
| return tk.render("package/resource_archive.html", extra_vars) | ||
|
|
||
|
|
||
| @bp.route('/dataset/<id>/archive/<activity_id>') |
There was a problem hiding this comment.
I'm not sure about "archive" to describe this. Maybe "history"?
@ckan/core any thoughts?
There was a problem hiding this comment.
as the method names are _archive maybe we should keep with that but also the option of _activities could have more sense as we use that in tests for the creation of the activities
| }) | ||
|
|
||
| try: | ||
| package = tk.get_action(u'package_show')(context, {u'id': id}) |
There was a problem hiding this comment.
Can we get rid of all the u prefixes on all new files? 🙏
(and maybe blackify them :p, or at least use double quotes consistently. but only the new ones!)
There was a problem hiding this comment.
Yes, I like this idea. I'll keep the current formatting till activity-pagination PR is merged so that there will be fewer conflicts. And then I'll run all activity-plugin files through black
|
This is good to go! @smotornyuk #6798 is also good to be merged. If I understood correctly in here we should merge #6798 first, then you pick the changes in this PR right? |
|
Updated. I think that all mentioned issues were addressed, so it's ready for the second round of review. |
|
@smotornyuk all good. Do you want to first merge this and then port the #6798 changes on a separate PR or add them here and then merge? |
|
Thanks @smotornyuk ! Next up, port the pagination changes to the user, group etc activity streams |
|
Thank you for the quick review:) @avdata99, this PR is merged, so you can use it for replicating your pagination-feature. I've tried to keep every bit of functionality from activity-streams intact and basically just moved the code and templates to the |
Just as the title says. If anybody doesn't like the idea and the text below will not convince them, feel free to close this PR. Its only aim is to simplify activity improvements in the future and it has no value other than that.
Why?
group changesfeature from the CKAN master on my projects using CKAN v2.9. If activities are implemented as an extension, I can just download theactivityextension from the upstream and register it asmy-activityextension, getting all the new features. And it will be much simpler to locate any incompatibilities and bugs, because the extension is not as huge, as the CKAN core itself.group changeswere not added to 2.9). And, do you remember that we have user activities, that are completely neglected by devs?:)modelproperty, it just containsckan.model. There is no way to add\override items there. So it has sense either to extend this item or remove it from context(if it is there for simplifying the import, it's better to move it into the toolkit).ckan.model.base:Baseinstance of SQLAlchemy's declarative base, which can be a solution for this problem.statsplugins depend on activities. If theactivityplugin is disabled, old stats can be shown, but there will be no updates to them.Details
ℹ️ I only moved the code and tried to keep all the features\details\bugs in place. All the improvements and refactoring can be done separately("Good for contribution").
I created the
activityplugin and moved almost everything related to activities into it:activityviewdashboard.indexpageWhat I left:
If you have
activityenabled, everything should work as it was before, but there are a couple of changes in code required:import ckan.model.Activity->import ckanext.activity.model.Activityurl_for("dataset/group/user.activity/changes/changes_multiple")->url_for("activity.package/group/user_activity/changes/changes_multiple")If the
activityplugin is not enabled:dashboard.datasetsinstead.If you are wondering, how activities are created, there is no magic. I've just used signals:)
PS sorry for another big PR