publiclab / plots2 Goto Github PK

Steps to reproduce (sufficient but perhaps more than necessary):

1. go to /signup
2. type in some junk that will cause errors and click sign up
3. when forwarded to /register, type in some more junk that will cause errors and click sign up
4. properly fill out the registry and type in something for the bio
5. once logged in as new user, look at profile and see lack of bio

That signup bio is not put in the database anywhere so far as I can tell.

just for fun, I did this again very simply and still see the problem:

1. go to /signup
2. type in valid information and something good in the bio, click sign up
3. once logged in as new user, look at profile and see lack of something good in bio
4. edit profile, change bio, see that it sticks

I think a seeds.rb file is the way to go to set up some example database entries, that would allow a freshly git cloneed copy of the code to be run right away. It would be easy to update it for modified models so that anyone forking the project could run the app right away and not get view-related errors.

It would also allow for a quick reset of the example data after some poking around in there.

I'll work on this right after finishing #34, so I'll have a better idea of what example entries to add to the DB.

finding this issue by clicking on a tag on any map page. for example "barataria"

the /maps page is taking 24 seconds!

thanks to using powertags for location storage. I want to figure out a better query but basically each map is getting map.lat and map.lon called. These alias to has_powertag('foo') which joins a couple tables EACH TIME. this was my code and I should be punished

however! I think caching is a bit dumb of a way to do this... gotta think of some better way. Even batch collecting all the tags or something, and assembling the joins in code, rather than as sequential queries... scrappy but it could work. this is a fairly unique page, anyways.

http://publiclab.org/tag/great-photos

I get redirected to /wiki and see:

That page has been moderated as spam. Please contact [email protected] if you believe there is a problem.That page has been moderated as spam. Please contact [email protected] if you believe there is a problem.

This could be a URL alias issue maybe if it has two aliases?

If a wiki page title has been changed, the search page returns the initial title and not the newest title.

I have to assume this will be a simple fix in the code from reading node.title to node.latest.title.

http://publiclab.org/map/pointe-aux-chenes-deep-lake-louisiana/2010-10-22

The revised title comes up in the search engine. This issue is probably not a bug but what do we think, should the urls update each time a title is revised?

Ideally, it should take fewer than 3 steps from start to finish and less than 10 minutes to cook.

I'm thinking we'll need to add water at some point.

Possibly heat.

On place pages (wikis) with "tabbed:notes" the "research" tab displays related research notes. These are not just notes that are tagged with that place name, and sometimes seemingly unrelated notes are included. For example, notes tagged with "chapter" always seem to be included for every place. The Jerusalem page includes notes from lots of places.

Just curious.

to avoid people deleting/spamming real pages whose titles have changed

We could reduce queries a lot by doing proper eager loading with a join between DrupalNode and DrupalUrlAlias (which requires a CONCAT() since DrupalUrlAlias.src = "node/#" where # is the node.nid) but I'm quite tempted to run a migration which just adds the drupalUrlAlias dst column as an additional DrupalNode column. We almost always need to get the URL and are no longer bound by the modularity rules of Drupal.

This is a tangent off of this closed issue: #33

same as this:

http://sourceforge.net/p/s3tools/bugs/90/

Make a button, visible to mods and admin only, which allows them to subscribe or unsubscribe to all research notes.

Not sure the best place to put this button. Dashboard, profile, both, or maybe the side panel?

The tag isn't actually in the database. There's some magical handling of a pretend tag id. See here:
https://github.com/jywarren/plots2/blob/master/app/mailers/subscription_mailer.rb#L65-L68

Unfortunately this special tag is only used in one place, so it is only defined in one place:
https://github.com/jywarren/plots2/blob/master/app/mailers/subscription_mailer.rb#L59

Maybe the magic all_tag should be hard coded into the tag model.

http://publiclab.org/tag/spectrometer

To curb spam, moderation is being proposed in issues like #11 .

Moderation should only be applied to users who aren't otherwise verified. Moderators and admin are implicitly verified.

Basic users are both verified and unverified. If basic were broken up into basic (unverified) and verified, the permission priority schedule might look more like: basic, verified, moderator, admin. Thus verified user is classified as such under DrupalUser.role or User.role.

Features which verified users have over basic users:

• preventative spam measures are not applied
• may vote to promote basic users to verified (this might enact the promotion or it might suggest it to mods/admin for review)
• may vote wiki and notes as spam (this might not unpublish/delete the wiki or note, but might suggest it to mods/admin for review)

It might be awhile until jywarren#160 (proper RBAC) is completed, since there weren't any obvious or highly recommended RBAC implementations in Ruby.

http://publiclab.org/blog

"A good place to frame NFL shirt" is showing up, but it is unpublished (as it has been marked as spam). Clicking on it while admin/moderator (maybe even just signed in?) shows it is "Unpublished". Clicking on it while not signed in just gives the usual 404 error.

At the april 2014 staff meeting we had some design brainstorming about how to make the front page of the site a little less cluttered. Not removing any important content; just organizing it under "megatabs". Supercedes jywarren#172

Using iOS I am unable to select anything on the nav bar (such as "Data"). Login link/system work fine

when detecting a "@" in the username in user_sessions controller

This link, which can be found on this research note http://publiclab.org/notes/ygzstc/04-30-2014/detection-of-olive-oil-adulteration-with-peanut-oil-using-visual-light-spectroscopy where i awarded an empiricism barnstar, leads to this bad path:

http://publiclab.org/wiki/barnstars#Barnstar:empirical+Barnstar

should be:
http://publiclab.org/wiki/barnstars#Empirical+Barnstar

I went to delete a spam message and got a 404: "There was an error. Are you sure you have the right address?", but I noticed there was still the "Switch to the old site" button in the upper right. I looked more closely at the menubar and found a number of things missing that is seen from the header on the front page.

Click here to see:
http://publiclab.org/notes/Liuzhuang19880717/10-24-2013/a-good-place-to-frame-nfl-shirt

I'm guessing someone else deleted the spam note before I got to it, leading to the 404. That is irrelevant to this ticket.

It could only affect /dashboard and /research -- we could publish with the notice "Research published. Your post will appear on the main listings within 30 minutes."

There are a bunch of spam wiki pages shown in the "recently edited wiki" list on my dashboard.

Clicking on them brings up the error page (404? 500? who knows)
http://publiclab.org/wiki/ought-to-you-pay-off-your-auto-title-loan-with-your-tax-refund

I can set the status to 0 in the database and make it go away. However, looking at the database, there is nothing obviously wrong with the record in node or the record in node_revisions. The page should load so that the delete button is easily accessed.

But many of these pages don't load. Their pageviews count is 0 on the wiki stats page:
http://publiclab.org/wiki

Production log indicates nid 9119 not found. That actual nid for the post is 9670.

Started GET "/wiki/ought-to-you-pay-off-your-auto-title-loan-with-your-tax-refund" for 108.20.246.226 at 2013-10-28 21:18:01 +0000
Processing by WikiController#show as HTML
  Parameters: {"id"=>"ought-to-you-pay-off-your-auto-title-loan-with-your-tax-refund"}
Completed 404 Not Found in 8ms

ActiveRecord::RecordNotFound (Couldn't find DrupalNode with nid=9119):
  app/models/drupal_url_alias.rb:7:in `node'
  app/models/drupal_node.rb:360:in `find_by_slug'
  app/controllers/wiki_controller.rb:8:in `show'

http://publiclab.org/tags

Research notes by location

    tid); if ($count) { /* don't show terms with 0 count */ echo("
    ".$term->name." (".$count.")
    "); } } /* end foreach */ ?> 

Research notes by tool

    tid); if ($count) { /* don't show terms with 0 count */ echo("
    ".$term->name." (".$count.")
    "); } } /* end foreach */ ?> 

This may be more of a personal preference. The ancillary info for each map page should only show up when those fields are used. Categories such as "cartographer's notes" are showing up when empty. I think it would look better/cleaner if those categories are only visible when they contain entries.

there should be a way to insert images into research note comments directly.

new subscription attempts not working. Tested on:

http://publiclab.org/subscribe/tag/pesticides
http://publiclab.org/subscribe/tag/air-quality

existing subscriptions are working for /profile/liz at least

only the base layer:
http://publiclab.org/archive

As per my message here: https://groups.google.com/forum/#!topic/plots-dev/QkKfqKStq88
I want to take a go at cleaning up the migrations and schema, which should provide these two benefits:

1. Easier and faster project setup - it should only take a couple of minutes from git clone to rake test or rails s to run smoothly.
2. Easier and faster project setup for production purposes eg. if the project switched servers and such.

At the moment, the best solution I've found is to add a migration that will add missing tables/columns as well as add/remove columns from what's already in the migrations.
This will update the schema to reflect the used database tables and it should allow for a smooth running application and tests. Finally, it'll shift development over to using migrations exclusively.

By the way, do you guys think the migration should additionally remove the unused tables or should they be left as they are?

git pull generates:

error: Your local changes to the following files would be overwritten by merge:
    db/schema.rb
Please, commit your changes or stash them before you can merge.
Aborting

I'm sure there's a best practice for this. Shall we not track schema.rb?

broke while publishing new map record. not sure what triggered it.

Or was this due to a direct database edit instead of deleting the wiki page through the web interface or rails model?

These pages don't exist anymore but their revisions are still showing up in the sidebar at /dashboard

Hmm, i went to /spam/wiki and they actually did exist -- but when you go to the wiki pages, it says they don't. Some other kind of wiki page creation going on here?

https://github.com/publiclab/plots2/blob/master/app/models/user.rb#L142-L148

This is not working for all profiles due to improper join; only some profiles correctly report the barnstars they have:

> nids = DrupalNode.find_all_by_uid(554, :conditions => {:type => "note"}, :order => "created DESC", :select => :nid).collect(&:nid)

node Columns (3.3ms)  SHOW FIELDS FROM `node`
DrupalNode Load (0.3ms)  SELECT nid FROM `node` WHERE `node`.`type` = 'note' AND `node`.`uid` = 554 ORDER BY created DESC
=> [8928, 8926, ... 1676, 1652, 1541, 831] 

> DrupalNodeCommunityTag.find :all, :conditions => ["name LIKE ? AND nid IN (?)",'barnstar:%',nids.join(',')], :joins => :drupal_tag

community_tags Columns (3.0ms)  SHOW FIELDS FROM `community_tags`
term_data Columns (2.2ms)  SHOW FIELDS FROM `term_data`
DrupalNodeCommunityTag Load (1.2ms)  SELECT `community_tags`.* FROM `community_tags` INNER JOIN `term_data` ON `term_data`.`tid` = `community_tags`.`tid` WHERE (name LIKE 'barnstar:%' AND nid IN ('8928,8926, ... 1541,831'))
=> [] 

However, manually changing it to outer join doesn't work either:

> DrupalNodeCommunityTag.find :all, :conditions => ["name LIKE ? AND nid IN (?) OUTER JOIN term_node ON term_node.tid = community_tags.tid",'barnstar:%',nids.join(',')]#, :joins => :drupal_tag

Mysql2::Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'OUTER JOIN term_node ON term_node.tid = community_tags.tid)' at line 1: SELECT `community_tags`.* FROM `community_tags`  WHERE (name LIKE 'barnstar:%' AND nid IN ('8928,8926, ... 1652,1541,831') OUTER JOIN term_node ON term_node.tid = community_tags.tid)

Github does this, it's great: ![Uploading mk2.png . . .]()

then large sets of images aren't just jumping around everywhere... they are placed immediately.

Every so often when I click publish wonky stuff just happens with saving all of the different entry data/thumbnail/tags. The form will reload with missing entry data. I

I tried the new Barnstar system by awarding Don a classic barnstar for this note: http://publiclab.org/notes/donblair/04-23-2014/meter-stick-reva-lights-buzzers-particulate-matter-oh-my.

Now that note is gone and so is Don's profile page.

I'm really sorry Don. I won't ever do it again.

Something in here: https://github.com/publiclab/plots2/blob/master/app/controllers/subscription_controller.rb#L106-L134

In order to determine how much spam is being received at any time, and how much is being handled by the community (admin/moderators), we should have some way to track historical spam even after it is deleted.

This might be as simple as something like a table that has a date that a node id and revision id were deleted, and possibly cache some information such as when the spam was created, who created it, and the last IP address of the creator. Usually this would be done relationally, but since the user, node, and revision might be deleted, this table should store copies of information and not pointers.

Recently we only had the 15 newest user profiles in the database, so I was able to read all of them. Of the 15, 3 were spam profiles.

Since we're now down to a manageable number of newly created users, we should add new user profiles to the moderate spam page. Instead of "title", it'll contain the profile contents.

https://publiclab.org/spam

Users could be removed from the list automatically after a few days to keep clutter down.

The ban button would be useful if the profile is obvious spam.

The Publish button would presently do nothing, since the profiles are published by default. But maybe it could expedite the usual timeout before a user is removed from the list.

We'll need a place in the database to indicate new users that are not yet vetted. This corresponds to the user status of ticket #11.

http://publiclab.org/maps/tag/barataria

enhancement to closed #31