Filters dev #225
Filters dev #225
Conversation
* The approach for the river filters is very much like that of the river channels - use of a config (config/filters.template.php) file to define the structure of the filter. As with channels and channel filter options, each filter has a set of filter parameters. This therefore introduces two new tables; river_filters and river_filter_parameters. * I've also relaxed CSRF token regeneration. The tokens are now tied to a user session. Once the session expires, the token also expires. This now allows POST requests to be processed from more than one browser tab * Deleted unused controllers and views from the repository * TODO: Implement geo-fence filter and introduce configuration parameter that will allow the site administrator to limit use of the river filters
* Suffix the update script with the name of the affected tables or relevant subject
* The post processor examines a drop and the river it's destined for vs its filter. If the drop doesn't match the filter, it's left out of the river. Since drops only get displayed when processing is complete, we have to purge them from their respective rivers before their processing status flag is flipped.
* Drops are only posted via the API once they've undergone post-processing so there's no need for the REST endpoint to return the list of freshly created drop entries * Discard use of "droplet_processed" field (performance impedance factor) when fetching drops since only processed drops get posted to the droplets table
| @@ -298,7 +300,6 @@ public static function get_droplets($user_id, $river_id, $drop_id = 0, $page = 1 | |||
| ->on('droplets.identity_id', '=', 'identities.id') | |||
| ->where('rivers_droplets.droplet_date_pub', '>', '0000-00-00 00:00:00') | |||
| ->where('rivers_droplets.river_id', '=', $river_id) | |||
There was a problem hiding this comment.
Missing ';' at the end of this line.
* The filters and channels are somewhat related so it makes more sense to place them next to each other in order to avoid cognitive dissonance. Recommended by @69mb
* A named filters facility to allow users to categorize the filters they would like to apply on their river. The named filters are ORd but the individual filter parameters in each named filter are ANDed * Improved the river creation process. Drops do not appear in a river until the user has completed the river creation i.e. clicks "View my River" in the finish page * Renamed the river_filter and river_filter_parameter tables to "filters" and "filter_parameters" respectively. This paves the way for bucket-level filters
* Run ".enable" or ".disable" events when a channel, filter or river is enabled or disabled
| -- ----------------------------------------------------- | ||
| CREATE TABLE IF NOT EXISTS `filters` ( | ||
| `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, | ||
| `filter_target` varchar(20) NOT NULL DEFAULT COMMENT 'Object on which the filter is to be applied i.e. river or bucket', |
There was a problem hiding this comment.
There is an error on this line ... has 'DEFAULT COMMENT ...' which is incorrect because COMMENT can't be a DEFAULT.
There was a problem hiding this comment.
Assuming this was supposed to be DEFAULT 'river' ?
|
|
Agreed. I ran out of terminology. Perhaps call them "Saved Filters" or something... |
Take a look at this gist for what I have in mind for the web.river.new message https://gist.github.com/2a4ea18343aadcc6d4a3 maybe this clarifies somewhat? RSS urls I think are part of channel configuration and can be left in channel_filter_options but the rss scheduler could listen for the new river event and update itself for rivers with an rss channel. |
|
I’ve completed a solid round of work in the /markup prototype that offers the “Flow” UI within an existing river’s settings. I’d like to bring a similar concept to the river creation process, next, as Emmanuel suggested earlier. You can find the “Flow” UI in the “ui-dev” branch of the SwiftRiver repo: https://github.com/ushahidi/SwiftRiver/tree/ui-dev As I discussed before, this approach offers the ability to save filters and distinguish them as either permanent or temporary—but through language on the frontend that’s more consistent with the rest of the app. SCREENSHOT: http://cl.ly/image/0Q1T2q0C0m2c To designate a group of filters as temporary, the user effectively makes the group “for their eyes only.” To do this, they select a filter group’s settings and designate “Who can see this group” as “Only you.” Then the filter is applied, but only for that user—it’s not part of the river’s overall makeup. Take a look and let me know if there are any holes for me to fill. |
|
Closing this pull request. Superseded by rules. |
Implements the river level filtering mechanism described in #188. The approach to the filters is the same as that of the channels on both the UX/UI but with slight modifications. The available filters are specified in
application/config/filters.php.templateRiver filters settings page
Activating a filter for use
Adding a filter parameter
