[allura:tickets] #8085 Add support for checkboxes to the markdown convertor
- **status**: open --> closed - **assigned_to**: Rohan Verma --> Shalitha Suranga - **Reviewer**: Dave Brondsema - **Comment**: Done in https://forge-allura.apache.org/p/allura/git/merge-requests/277/ --- ** [tickets:#8085] Add support for checkboxes to the markdown convertor** **Status:** closed **Milestone:** unreleased **Created:** Thu May 19, 2016 08:58 PM UTC by Rohan Verma **Last Updated:** Sun Sep 02, 2018 06:22 AM UTC **Owner:** Shalitha Suranga Checkboxes can be rendered from [ ] and [x] It is useful for maintaining lists and TODOs --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #7788 Upgrade mongo on allura-vm
- **status**: open --> closed --- ** [tickets:#7788] Upgrade mongo on allura-vm** **Status:** closed **Milestone:** unreleased **Labels:** asf **Created:** Thu Oct 30, 2014 07:59 PM UTC by Dave Brondsema **Last Updated:** Fri Oct 02, 2015 03:26 PM UTC **Owner:** nobody Label suggestions don't work, since they require mongodb aggregation. We have an old version of mongo and should upgrade it. Perhaps upgrading to next stable ubuntu release would include it (check with infra before doing it) --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8228 How to delete external links
- **status**: open --> closed --- ** [tickets:#8228] How to delete external links** **Status:** closed **Milestone:** unreleased **Created:** Sat Sep 08, 2018 01:19 PM UTC by Shalitha Suranga **Last Updated:** Tue Sep 11, 2018 05:15 PM UTC **Owner:** nobody I added several external links to my local forge. Tried to delete those. Is there option to delete external links? --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8227 Personal Dashboard - Reduce ticket table columns
- **status**: in-progress --> closed - **Reviewer**: Dave Brondsema --- ** [tickets:#8227] Personal Dashboard - Reduce ticket table columns** **Status:** closed **Milestone:** unreleased **Labels:** Personal Dashboard **Created:** Fri Sep 07, 2018 04:08 PM UTC by Deshani **Last Updated:** Fri Sep 07, 2018 04:08 PM UTC **Owner:** Deshani --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] Ticket 7708 discussion
I don't know offhand exactly what the right logic would be, but it does sound complicated and we'll have to test all the possibilities pretty thoroughly. It seems like it'd be nice to keep it as spaces in the database, since that's what really is intended. But then the code that handles URLs should accept either underscore or space, and probably the code that generates the links for wikis should turn spaces into underscores so that format actually is what people see. I might not be thinking of all the issues right now though. I think % in a name is ok still, because with url-encoding that turns into %25 --- ** [tickets:#7708] Reference wiki pages that contain spaces using underscores** **Status:** open **Milestone:** unreleased **Created:** Mon Sep 22, 2014 05:24 PM UTC by Wayne Davison **Last Updated:** Mon Sep 03, 2018 09:16 AM UTC **Owner:** nobody It would be nice to avoid the ugliness of %20 sequences in wiki URLs for each space. One solution would be to allow the url to contain an underscore for each space character and still be able to find the page. As for potential ambiguity in page names, either the wiki would need to treat the names as identical (so that ambiguous pages could not be created) or it would have to prefer finding a page with more underscore matches. I personally think that the former is preferable, which would mean that if I try to create a page named both "foo_bar" and "foo bar" that I'm told that the page exists. The alterntive is for a request for "foo_bar_baz" to find "foo_bar baz" in preference to "foo bar baz" if "foo_bar_baz" doesn't exist and the other 2 do (due to it having more matching underscores). --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8225 Component delete everything end up with 404
Yes that sounds like a good idea. One way that would not be needed, though, is if you delete the tool when you are are on different page (using the unlocked toolbar admin). So maybe the delete controller can check to the referrer to know if it should stay on the referer or use the project root page to avoid 404. --- ** [tickets:#8225] Component delete everything end up with 404** **Status:** open **Milestone:** unreleased **Created:** Tue Sep 04, 2018 05:57 PM UTC by Shalitha Suranga **Last Updated:** Tue Sep 04, 2018 05:57 PM UTC **Owner:** nobody **Step to reproduce ** Select wiki, ticket or forum -> Delete everything Then user will be redirected to **404 - We're sorry but we weren't able to process this request.** Can we redirect to project root page instead? Your ideas --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8228 How to delete external links
You should be able to unlock the toolbar (lock icon on the right) and then there is a gear icon next to each tool. You can click on it and choose "delete everything" for the link. --- ** [tickets:#8228] How to delete external links** **Status:** open **Milestone:** unreleased **Created:** Sat Sep 08, 2018 01:19 PM UTC by Shalitha Suranga **Last Updated:** Sat Sep 08, 2018 01:19 PM UTC **Owner:** nobody I added several external links to my local forge. Tried to delete those. Is there option to delete external links? --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Re: forge-allura update
Yep, since we have Updated Date I was thinking that Created Date wasn't as important. And Milestone didn't seem as important either (but maybe is for some people). Hopefully that's enough to make it a table full of real tickets fit better. On 9/7/18 11:47 AM, Deshani Geethika wrote: > Hi Dave, > > What you meant by "Created" column is "Created Date" right? > > On Fri, Sep 7, 2018 at 9:07 AM Shalitha Suranga > wrote: > >> Hi.. >> >> Great,, Dashboard looks very useful. >> >> On Fri, Sep 7, 2018 at 8:07 AM Deshani Geethika >> >> wrote: >> >>> Yeah that's good. I'll do the modifications >>> >>> On Fri, Sep 7, 2018 at 3:27 AM Dave Brondsema >> wrote: >>> >>>> I've updated https://forge-allura.apache.org/ to our latest code, >> since >>> it >>>> hadn't been updated for many months. Also made a little script at >>>> /allura-data/update-allura.sh on the server to make updating easier, >>>> hopefully >>>> will fully-automate it at some point. >>>> >>>> This includes all of Deshani's Google Summer of Code work on the >>>> dashboard, so >>>> we can see it in action! (I do notice my tickets table is too wide to >>> fit, >>>> though, maybe we can remove the Milestone and Created columns?) >>>> >>>> >>>> -- >>>> Dave Brondsema : d...@brondsema.net >>>> http://www.brondsema.net : personal >>>> http://www.splike.com : programming >>>> <>< >>>> >>> >>> >>> -- >>> *Deshani Geethika* >>> Undergraduate at Department of Computer Science and Engineering >>> Faculty of Engineering - University of Moratuwa Sri Lanka >>> LinkedIn <https://www.linkedin.com/in/deshanigeethika/> | GitHub >>> <https://github.com/deshanigtk> | Mobile - +94776383034 >>> >> >> >> -- >> Regards, >> >> *Shalitha Suranga Bsc. CS (UG)* >> Director - Software Developer >> PCL Marketing - Sri Lanka >> www.pclmarketing.com >> >> +94 71 985 584 3 (Whatsapp/Viber), +94 77 42 750 65 >> www.shalithasuranga.me >> > > -- Dave Brondsema : d...@brondsema.net http://www.brondsema.net : personal http://www.splike.com : programming <><
forge-allura update
I've updated https://forge-allura.apache.org/ to our latest code, since it hadn't been updated for many months. Also made a little script at /allura-data/update-allura.sh on the server to make updating easier, hopefully will fully-automate it at some point. This includes all of Deshani's Google Summer of Code work on the dashboard, so we can see it in action! (I do notice my tickets table is too wide to fit, though, maybe we can remove the Milestone and Created columns?) -- Dave Brondsema : d...@brondsema.net http://www.brondsema.net : personal http://www.splike.com : programming <><
[allura:tickets] #8226 Personal Dashboard - Fix dashboard logo
- **status**: in-progress --> closed - **Reviewer**: Dave Brondsema --- ** [tickets:#8226] Personal Dashboard - Fix dashboard logo** **Status:** closed **Milestone:** unreleased **Labels:** Personal Dashboard **Created:** Wed Sep 05, 2018 02:57 AM UTC by Deshani **Last Updated:** Wed Sep 05, 2018 02:57 AM UTC **Owner:** Deshani --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Re: Regarding merge request #274
Thanks, that's a nice fix. I've merged it! On 9/3/18 7:28 AM, Shalitha Suranga wrote: > Hi.. > > I am interested in alura project and submitted very very simple fix via > https://forge-allura.apache.org/p/allura/git/merge-requests/274/ just to > start contributing > > Can someone review and merge it . I need to familiarize further with allura > and like to contribute by fixing issues and writing some code > > Cheers! > -- Dave Brondsema : d...@brondsema.net http://www.brondsema.net : personal http://www.splike.com : programming <><
[allura:tickets] #8224 Ticket subscriptions orphaned when moving tickets
- **status**: in-progress --> review - **Comment**: Fixed on db/8224 --- ** [tickets:#8224] Ticket subscriptions orphaned when moving tickets** **Status:** review **Milestone:** unreleased **Created:** Fri Aug 31, 2018 05:06 PM UTC by Dave Brondsema **Last Updated:** Fri Aug 31, 2018 05:06 PM UTC **Owner:** Dave Brondsema When a ticket is moved from one tracker to another, the subscription for it is orphaned. Anyone subscribed to the original ticket only (and not to the destination tracker) will not get a notification that it moved or any further updates. The subscription record still exists for the original moved ticket. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8224 Ticket subscriptions orphaned when moving tickets
--- ** [tickets:#8224] Ticket subscriptions orphaned when moving tickets** **Status:** in-progress **Milestone:** unreleased **Created:** Fri Aug 31, 2018 05:06 PM UTC by Dave Brondsema **Last Updated:** Fri Aug 31, 2018 05:06 PM UTC **Owner:** Dave Brondsema When a ticket is moved from one tracker to another, the subscription for it is orphaned. Anyone subscribed to the original ticket only (and not to the destination tracker) will not get a notification that it moved or any further updates. The subscription record still exists for the original moved ticket. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Re: [GSoC] [COMDEV-254] Allura - Personal Dashboard
Hi! I've merged that merge request, it looks good. I think the title text is ok. The layout of the logo runs into the main gray content though. It'd be nice if it had a bit of space like it does on the user profile page, for example. I see on the user profile page there is an empty that helps push it down. Another thing that could be polished is the placement of the Activity box in the right column. On both the dashboard and the profile pages it is part way down the column, and I think it'd be better at the top of the column. That might be fixable by CSS rules, but also by the ordering of the widgets. If it is the first widget then when it floats to the right its ok at the top of the column. So either by code, or .ini config file you could make it first in the profile_sections.order and personal_dashboard_sections.order On 8/29/18 6:44 AM, Deshani Geethika wrote: > Hi Dave, > > Sorry for the delays. I've done some fixes on dashboard styles and added a > merge request ( > https://forge-allura.apache.org/p/allura/git/merge-requests/271/) > Please review it and let me know if any improvements required. > > Also, for the dashboard title, currently it is shown as *username / > Dashboard *(eg: Admin1 / Dashboard). Is it alright? Otherwise, do you have > a better idea for the dashboard title? > > Regards! > > On Fri, Jul 27, 2018 at 9:17 PM Deshani Geethika > wrote: > >> Thanks a lot. Will try these and let you know >> >> On Fri, Jul 27, 2018 at 8:52 PM Dave Brondsema wrote: >> >>> Sure, here's some thoughts: >>> >>> Inheriting from TestGitRepo means it gets all the test_* functions, so >>> when I >>> ran nosetests, it ran a lot of TestGitRepo.test_* tests too, which we >>> don't want >>> to happen. So I'd remove that inheritance. You probably will have to >>> duplicate >>> the setup_with_tools() function in this file then. >>> >>> Actually, inheriting from _TestCase in >>> forgegit/tests/functional/test_controllers.py might be a good option. It >>> has >>> some setup functions you can use (so you don't have to duplicate >>> setup_with_tools) and it doesn't have any test_* functions. >>> >>> The super() call is supposed to use its own name, like >>> super(TestMergeRequestsSection, self).setUp() Not sure if that makes a >>> difference here or not. >>> >>> merge_request() is a function but you don't have parenthesis on `mr= >>> self.merge_request` so that function isn't running. >>> >>> I realized what happened earlier when I didn't see the "Tickets" section >>> in the >>> HTML output of the tickets test! When I was trying this test now, I got a >>> similar situation where the "Merge Requests" section isn't in the HTML >>> output at >>> all either. So I looked in the 'test.log' file (where logging goes to >>> during >>> tests) and saw "Error rendering section MergeRequestsSection: ..." with >>> error >>> details. So these sections trap errors and log them, instead of letting >>> the >>> whole page error. So looking at the test.log output can help see those >>> errors >>> when they happen. >>> >>> You may need to run ThreadLocalODMSession.flush_all() after creating the >>> merge >>> request object. That is a common test pattern we have when tests create >>> something and then need to view it. (Mainly needed in tests, since >>> regular web >>> pages will flush at the end of each request). >>> >>> Hope that helps, let me know how far you get, and I can look at it some >>> more if >>> needed :) >>> >>> On 7/27/18 9:11 AM, Deshani Geethika wrote: >>>> Hi Dave, >>>> >>>> I have started to write a test case for Merge Requests Section. For >>> that I >>>> have followed ForgeGit tests but it doesn't work for me. I was trying to >>>> create a merge request and see whether it appears in dashboard. >>>> >>>> I've pushed the code into my fork >>>> < >>> https://forge-allura.apache.org/u/deshani/allura-personal-dashboard/ci/96613c7854d116130455a343c814e853c2b5d812/ >>>> . >>>> Can you kindly take a look at that? Also, please let me know any >>> debugging >>>> process can be done for methods called internally when creating a merge >>>> request. >>>> >>>> Regards! >>>> >>>> On Tue, Jul 17, 2018 at 11:19 PM Deshani Geethika
[allura:tickets] Re: #8204 Create new neighbourhood
It is not in a released version yet. But it is on the "master" branch of allura, so if you are using a git checkout of Allura you can update to the latest and use it. --- ** [tickets:#8204] Create new neighbourhood** **Status:** open **Milestone:** unreleased **Created:** Fri Jun 08, 2018 06:15 AM UTC by Vrinda **Last Updated:** Sun Aug 26, 2018 06:38 AM UTC **Owner:** nobody Hello, I understand neighbourhoods can be used for grouping similar projects. By default I can see 3 neighbourhoods created by default : Adobe, Projects and Users. Is it possible to create new neighbourhood? Regards, Vrinda. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] Re: #8085 Add support for checkboxes to the markdown convertor
Hi Shalitha, I haven't tried this myself, so I'm not sure what all the challenges will be exactly, but I looked into it a little bit right now. The ForgeLinkTreeProcessor code adds `[` and `]` around existing links like `[SomeWikiPage]`, so shouldn't affect `[ ]` and only maybe `[x]` if there is a page called `x`. It could be customized to inspect the node properties & text more if needed to apply only in certain situations. It looks like there is an extension for markdown to implement the checkbox idea, might be good to try using that rather than writing something from scratch: https://github.com/FND/markdown-checklist --- ** [tickets:#8085] Add support for checkboxes to the markdown convertor** **Status:** open **Milestone:** unreleased **Created:** Thu May 19, 2016 08:58 PM UTC by Rohan Verma **Last Updated:** Sat Aug 18, 2018 05:41 PM UTC **Owner:** Rohan Verma Checkboxes can be rendered from [ ] and [x] It is useful for maintaining lists and TODOs --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] Ticket 7708 discussion
Related work for email addresses of wiki pages with spaces in them was done in [7a92cb] --- ** [tickets:#7708] Reference wiki pages that contain spaces using underscores** **Status:** open **Milestone:** unreleased **Created:** Mon Sep 22, 2014 05:24 PM UTC by Wayne Davison **Last Updated:** Thu Jan 29, 2015 07:12 PM UTC **Owner:** nobody It would be nice to avoid the ugliness of %20 sequences in wiki URLs for each space. One solution would be to allow the url to contain an underscore for each space character and still be able to find the page. As for potential ambiguity in page names, either the wiki would need to treat the names as identical (so that ambiguous pages could not be created) or it would have to prefer finding a page with more underscore matches. I personally think that the former is preferable, which would mean that if I try to create a page named both "foo_bar" and "foo bar" that I'm told that the page exists. The alterntive is for a request for "foo_bar_baz" to find "foo_bar baz" in preference to "foo bar baz" if "foo_bar_baz" doesn't exist and the other 2 do (due to it having more matching underscores). --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Re: Regarding mailing list subscription email
Hi Shalitha, That page is an old and obscure page, the main one is at https://allura.apache.org/ Do you know how you found that page? Maybe there is a link somewhere else that needs to be updated. Thanks On 8/17/18 10:28 PM, Shalitha Suranga wrote: > Hello > > I was going to subscribe in to dev updates and put mail into > allura-dev-subscr...@incubator.apache.org as displayed in > > https://svn.apache.org/repos/infra/websites/production/allura/content/allura/mailing-lists.html > > But allura-dev-subscr...@apache.org worked not > allura-dev-subscr...@incubator.apache.org > > I think above page needs to be updated with new email address > > Thanks > -- Dave Brondsema : d...@brondsema.net http://www.brondsema.net : personal http://www.splike.com : programming <><
[allura:tickets] #8200 Update GitPython to support git >= 2.15
- **status**: in-progress --> review - **Comment**: db/8200 has the changes - ended up being very straightforward --- ** [tickets:#8200] Update GitPython to support git >= 2.15** **Status:** review **Milestone:** unreleased **Created:** Mon Apr 30, 2018 04:23 PM UTC by Dave Brondsema **Last Updated:** Thu Aug 09, 2018 09:19 PM UTC **Owner:** Dave Brondsema With Git >= 2.15 we get errors like `TypeError: PackingType of packed-Refs not understood: '# pack-refs with: peeled fully-peeled sorted'` which is fixed in a newer version of GitPython: https://github.com/gitpython-developers/GitPython/issues/687 https://github.com/gitpython-developers/GitPython/pull/689 That will be a big upgrade so we should so thorough testing. Also we should try to get some GitPython fixes merged into upstream if they haven't yet. At https://github.com/johnsca/GitPython/tree/sf-master there are fixes for [#5411], [#6000], [#6078], and [#7021]. (SourceForge uses a custom build that includes those fixes, but Allura's requirements.txt version doesn't include those) --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8200 Update GitPython to support git >= 2.15
Changes from 0.3.2 to 2.1.11 that may affect us: > 2.0.0 > CRITICAL: Diff objects created with patch output will now not carry the — and > +++ header lines anymore. All diffs now start with the @@ header line > directly. Users that rely on the old behaviour can now (reliably) read this > information from the a_path and b_path properties without having to parse > these lines manually. Don't see any evidence of this being used by Allura. > 1.0.2 > IMPORTANT: Changed default object database of Repo objects to GitCmdObjectDB. > The pure-python implementation used previously usually fails to release its > resources (i.e. file handles), which can lead to problems when working with > large repositories. We already use GitCmdObjectDB > 0.3.4. > Id attribute of Commit objects is now hexsha, instead of binsha. The latter > makes no sense in python 3 and I see no application of it anyway besides its > artificial usage in test cases. Looks like `binsha` attribute still exists, so our continued usage of it should be ok. A nice new feature that could be used (esp. in last_commit_doc computations): https://gitpython.readthedocs.io/en/stable/reference.html#git.cmd.Git.execute `kill_after_timeout` parameter. Make sure to `pip uninstall gitdb smmap` so they aren't installed alongside the gitdb2 and smmap2 packages. The custom patches at https://github.com/johnsca/GitPython/commits/sf-master have been applied upstream already, except for https://github.com/johnsca/GitPython/commit/f7ed51ba4c8416888f5744ddb84726316c461051 which seems pretty minor and probably was just handled differently overall. --- ** [tickets:#8200] Update GitPython to support git >= 2.15** **Status:** in-progress **Milestone:** unreleased **Created:** Mon Apr 30, 2018 04:23 PM UTC by Dave Brondsema **Last Updated:** Thu Aug 09, 2018 08:23 PM UTC **Owner:** Dave Brondsema With Git >= 2.15 we get errors like `TypeError: PackingType of packed-Refs not understood: '# pack-refs with: peeled fully-peeled sorted'` which is fixed in a newer version of GitPython: https://github.com/gitpython-developers/GitPython/issues/687 https://github.com/gitpython-developers/GitPython/pull/689 That will be a big upgrade so we should so thorough testing. Also we should try to get some GitPython fixes merged into upstream if they haven't yet. At https://github.com/johnsca/GitPython/tree/sf-master there are fixes for [#5411], [#6000], [#6078], and [#7021]. (SourceForge uses a custom build that includes those fixes, but Allura's requirements.txt version doesn't include those) --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8074 Show full commit diff in commit_browser
Another quirk of the commit_browser display, is that directories are shown as changed, and the "diff" link for them doesn't go anywhere useful. We don't show directories as changed in the full commit page, which is better I think. --- ** [tickets:#8074] Show full commit diff in commit_browser** **Status:** open **Milestone:** unreleased **Created:** Thu Apr 07, 2016 02:39 PM UTC by Tim Smith **Last Updated:** Thu Apr 07, 2016 02:39 PM UTC **Owner:** nobody There's no easy way to get to https://sourceforge.net/p/tortoisesvn/code/27258/ (view a commit including all diffs) from https://sourceforge.net/p/tortoisesvn/code/commit_browser . It seems that should be a prominent link after clicking on the commit, but the only way I can get to it is click “Parent” and then “Child” links (or going to the "History" link instead of "Browse Commits". Also, it would be great to ALSO have the option to view all diffs right there on the commit_browser page. Either show that automatically, or if that's too slow then have a "Show diffs" button that expands in situ to show the diffs. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8200 Update GitPython to support git >= 2.15
- **status**: open --> in-progress - **assigned_to**: Dave Brondsema --- ** [tickets:#8200] Update GitPython to support git >= 2.15** **Status:** in-progress **Milestone:** unreleased **Created:** Mon Apr 30, 2018 04:23 PM UTC by Dave Brondsema **Last Updated:** Mon Apr 30, 2018 04:23 PM UTC **Owner:** Dave Brondsema With Git >= 2.15 we get errors like `TypeError: PackingType of packed-Refs not understood: '# pack-refs with: peeled fully-peeled sorted'` which is fixed in a newer version of GitPython: https://github.com/gitpython-developers/GitPython/issues/687 https://github.com/gitpython-developers/GitPython/pull/689 That will be a big upgrade so we should so thorough testing. Also we should try to get some GitPython fixes merged into upstream if they haven't yet. At https://github.com/johnsca/GitPython/tree/sf-master there are fixes for [#5411], [#6000], [#6078], and [#7021]. (SourceForge uses a custom build that includes those fixes, but Allura's requirements.txt version doesn't include those) --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8222 TestForumMessageHandling fails occasionally
--- ** [tickets:#8222] TestForumMessageHandling fails occasionally** **Status:** open **Milestone:** unreleased **Created:** Thu Aug 02, 2018 02:38 PM UTC by Dave Brondsema **Last Updated:** Thu Aug 02, 2018 02:38 PM UTC **Owner:** nobody The jenkins build sometimes fails with this: ~~~ == ERROR: forgediscussion.tests.functional.test_forum.TestForumMessageHandling.test_posts -- Traceback (most recent call last): File "<https://builds.apache.org/job/Allura/ws/.allura-venv/local/lib/python2.7/site-packages/nose/case.py;,> line 197, in runTest self.test(*self.arg) File "<https://builds.apache.org/job/Allura/ws/ForgeDiscussion/forgediscussion/tests/functional/test_forum.py;,> line 248, in test_posts r = self.app.get(url, params=dict(version='1')) File "<https://builds.apache.org/job/Allura/ws/AlluraTest/alluratest/validation.py;,> line 322, in get resp = super(ValidatingTestApp, self).get(*args, **kw) File "<https://builds.apache.org/job/Allura/ws/AlluraTest/alluratest/validation.py;,> line 269, in get return super(PostParamCheckingTestApp, self).get(*args, **kwargs) File "<https://builds.apache.org/job/Allura/ws/.allura-venv/local/lib/python2.7/site-packages/webtest/app.py;,> line 756, in get expect_errors=expect_errors) File "<https://builds.apache.org/job/Allura/ws/.allura-venv/local/lib/python2.7/site-packages/webtest/app.py;,> line 1099, in do_request res = req.get_response(app, catch_exc_info=True) File "<https://builds.apache.org/job/Allura/ws/.allura-venv/local/lib/python2.7/site-packages/webob/request.py;,> line 1049, in get_response application, catch_exc_info=True) File "<https://builds.apache.org/job/Allura/ws/.allura-venv/local/lib/python2.7/site-packages/webob/request.py;,> line 1022, in call_application app_iter = application(self.environ, start_response) File "<https://builds.apache.org/job/Allura/ws/.allura-venv/local/lib/python2.7/site-packages/webtest/lint.py;,> line 179, in lint_app iterator = application(environ, start_response_wrapper) File "<https://builds.apache.org/job/Allura/ws/.allura-venv/local/lib/python2.7/site-packages/pylons/middleware.py;,> line 150, in __call__ self.app, environ, catch_exc_info=True) File "<https://builds.apache.org/job/Allura/ws/.allura-venv/local/lib/python2.7/site-packages/pylons/util.py;,> line 51, in call_wsgi_application output.extend(app_iter) File "<https://builds.apache.org/job/Allura/ws/.allura-venv/local/lib/python2.7/site-packages/paste/registry.py;,> line 409, in streaming_iter for item in self.application(environ, start_response): File "<https://builds.apache.org/job/Allura/ws/.allura-venv/local/lib/python2.7/site-packages/ming/odm/middleware.py;,> line 29, in __call__ result = self.app(environ, start_response) File "<https://builds.apache.org/job/Allura/ws/Allura/allura/lib/custom_middleware.py;,> line 60, in __call__ return self.app(environ, start_response) File "<https://builds.apache.org/job/Allura/ws/.allura-venv/local/lib/python2.7/site-packages/ew/middleware.py;,> line 65, in __call__ result = self.app(environ, start_response) File "<https://builds.apache.org/job/Allura/ws/Allura/allura/lib/custom_middleware.py;,> line 260, in __call__ return resp(environ, start_response) File "<https://builds.apache.org/job/Allura/ws/Allura/allura/config/middleware.py;,> line 207, in AlluraGlobalsMiddleware return app(environ, start_response) File "<https://builds.apache.org/job/Allura/ws/Allura/allura/lib/custom_middleware.py;,> line 214, in __call__ return self._app(environ, session_start_response) File "<https://builds.apache.org/job/Allura/ws/.allura-venv/local/lib/python2.7/site-packages/timermiddleware/__init__.py;,> line 202, in __call__ resp = req.get_response(self.app) File "<https://builds.apache.org/job/Allura/ws/.allura-venv/local/lib/python2.7/site-packages/webob/request.py;,> line 1053, in get_response application, catch_exc_info=False) File "<https://builds.apache.org/job/Allura/ws/.allura-venv/local/lib/python2.7/site-packages/webob/request.py;,> line 1022, in call_application app_iter = application(self.environ, start_response) File "<https://builds.apache.org/job/Allura/ws/Allura/allura/lib/custom_middleware.py;,> line 153, in __call__ self.app, environ, catch_exc_info=True) File "<https://builds.apache.org/job/Allura/ws/.allura-venv/local/lib/python2.7/site-packages/pylons/util.py;,> line 48, in call_wsgi_application app_iter = application(environ, start_resp
Re: [GSoC] [COMDEV-254] Allura - Personal Dashboard
Sure, here's some thoughts: Inheriting from TestGitRepo means it gets all the test_* functions, so when I ran nosetests, it ran a lot of TestGitRepo.test_* tests too, which we don't want to happen. So I'd remove that inheritance. You probably will have to duplicate the setup_with_tools() function in this file then. Actually, inheriting from _TestCase in forgegit/tests/functional/test_controllers.py might be a good option. It has some setup functions you can use (so you don't have to duplicate setup_with_tools) and it doesn't have any test_* functions. The super() call is supposed to use its own name, like super(TestMergeRequestsSection, self).setUp() Not sure if that makes a difference here or not. merge_request() is a function but you don't have parenthesis on `mr= self.merge_request` so that function isn't running. I realized what happened earlier when I didn't see the "Tickets" section in the HTML output of the tickets test! When I was trying this test now, I got a similar situation where the "Merge Requests" section isn't in the HTML output at all either. So I looked in the 'test.log' file (where logging goes to during tests) and saw "Error rendering section MergeRequestsSection: ..." with error details. So these sections trap errors and log them, instead of letting the whole page error. So looking at the test.log output can help see those errors when they happen. You may need to run ThreadLocalODMSession.flush_all() after creating the merge request object. That is a common test pattern we have when tests create something and then need to view it. (Mainly needed in tests, since regular web pages will flush at the end of each request). Hope that helps, let me know how far you get, and I can look at it some more if needed :) On 7/27/18 9:11 AM, Deshani Geethika wrote: > Hi Dave, > > I have started to write a test case for Merge Requests Section. For that I > have followed ForgeGit tests but it doesn't work for me. I was trying to > create a merge request and see whether it appears in dashboard. > > I've pushed the code into my fork > <https://forge-allura.apache.org/u/deshani/allura-personal-dashboard/ci/96613c7854d116130455a343c814e853c2b5d812/>. > Can you kindly take a look at that? Also, please let me know any debugging > process can be done for methods called internally when creating a merge > request. > > Regards! > > On Tue, Jul 17, 2018 at 11:19 PM Deshani Geethika > wrote: > >> Hi Dave, >> >> Thank you for sharing these valuable information. I have added a merge >> request <https://forge-allura.apache.org/p/allura/git/merge-requests/269/>. >> Please review it and let me know any further improvements. >> >> Regards! >> >> On Mon, Jul 16, 2018 at 9:54 PM Dave Brondsema wrote: >> >>> On 7/16/18 9:49 AM, Deshani Geethika wrote: >>>> Hi Dave, >>>> >>>> I have tried with adding above lines, but still doesn't work. Can you >>> take >>>> a look at my implementation >>>> < >>> https://forge-allura.apache.org/u/deshani/allura-personal-dashboard/ci/a7ddd0c0bbcfe89cb14fc5214deff168cbb20477/ >>>> >>>> ? >>>> >>>> Thanks! >>>> >>> >>> Here's some debugging process I did, you can try it too: >>> >>> Tests use the MockSOLR class instead of a real solr instance (so that you >>> don't >>> need solr to run tests). I knew that, so I started by going to >>> MockSOLR.search() and putting in some print statements to debug it. At >>> the >>> beginning of search() I added: >>> >>> print q >>> print fq >>> >>> And inside the "for obj in self.db.values():" loop, I added "print obj" >>> >>> My idea was to see what query is happening and what the stored objects >>> are, and >>> see what's not working. I ran just the single test with `nosetests >>> >>> allura.tests.functional.test_personal_dashboard:TestTicketsSection.test_tickets_section` >>> I noticed there was a 'project_id_s' in the search query, and there >>> shouldn't >>> be. But after a bit of trial & error to see what was happening, I >>> realized that >>> was coming from a "update_bin_count" background task, and that wasn't >>> related to >>> the test really. >>> >>> So I commented-out the tasks M.MonQTask.run_ready() to avoid all the >>> background >>> tasks for now and did it again, and there wasn't any of my print >>> statements >>> occurring. So the dashboard ticket search wasn't even happ
[allura:tickets] Re: #8204 Create new neighbourhood
Those are not part of the open source Allura, sorry --- ** [tickets:#8204] Create new neighbourhood** **Status:** open **Milestone:** unreleased **Created:** Fri Jun 08, 2018 06:15 AM UTC by Vrinda **Last Updated:** Thu Jul 26, 2018 12:34 PM UTC **Owner:** nobody Hello, I understand neighbourhoods can be used for grouping similar projects. By default I can see 3 neighbourhoods created by default : Adobe, Projects and Users. Is it possible to create new neighbourhood? Regards, Vrinda. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8219 Personal Dashboard - Test Tickets section
- **status**: in-progress --> closed - **Reviewer**: Dave Brondsema - **Comment**: Merged in https://forge-allura.apache.org/p/allura/git/merge-requests/269/ --- ** [tickets:#8219] Personal Dashboard - Test Tickets section** **Status:** closed **Milestone:** unreleased **Labels:** Personal Dashboard **Created:** Fri Jul 13, 2018 12:00 PM UTC by Deshani **Last Updated:** Fri Jul 13, 2018 12:00 PM UTC **Owner:** Deshani --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Re: [GSoC] [COMDEV-254] Allura - Personal Dashboard
My first thought is that it probably is not getting indexed in solr. That runs in a background task, so during tests it won't happen automatically. Try adding this: ThreadLocalORMSession.flush_all() M.MonQTask.run_ready() ThreadLocalORMSession.flush_all() The run_ready() call will run the background tasks that are queued up. The flush_all() lines might not be necessary, but I see them in other tests. You can try with and without them. What they do is ensure all changes to models are flushed to mongo. Let me know if that doesn't help and I'll take a closer look. On 7/13/18 8:41 AM, Deshani Geethika wrote: > Hi Dave, > > I have started to create a test case for Tickets Section. > > I was trying to create a new ticket and check whether it appears in > Dashboard, but it doesn't work. It seems like I've done something wrong > when creating new ticket. > > Could you kindly take a look at my implementation > <https://forge-allura.apache.org/u/deshani/allura-personal-dashboard/ci/56062d5c56aad503e022727b0dd5b67d37133b2e/> > and help me to sort out the issue? > > Thanks! > > On Thu, Jul 12, 2018 at 10:04 PM Deshani Geethika > wrote: > >> Thanks. I'll start working on it and give you updates >> >> On Thu, Jul 12, 2018 at 8:57 PM Dave Brondsema wrote: >> >>> I think it would be good to have a test of each of the sections. At least >>> tickets & merge requests. For projects and activity, they are very >>> similar & >>> re-use code from the profile sections. So you could either copy the test >>> structure and have very similar tests to the user profile tests, or omit >>> the >>> tests for those. >>> >>> For tickets & merge requests I think good tests would create a few >>> tickets (or >>> merge requests) and then get the /dashboard URL and assert that they >>> showed up. >>> The ForgeTracker suite should have plenty of examples of making tickets >>> without >>> having to do mocking probably. To make a merge request, >>> allura.tests.model.test_repo.TestMergeRequest has an abstract test that >>> uses >>> some mocking. It'd be better though to use a more real merge request like >>> ForgeGit's tests do. >>> >>> >>> On 7/11/18 1:06 PM, Deshani Geethika wrote: >>>> Hi Dave, >>>> >>>> I've created a test case for Dashboard sections and added a merge >>> request >>>> <https://forge-allura.apache.org/p/allura/git/merge-requests/268/>. >>> Please >>>> review it and let me know if any improvements required. >>>> >>>> Also, could you let me know what are the other functionalities should be >>>> tested in Dashboard? >>>> >>>> Regards! >>>> >>>> On Sat, Jul 7, 2018 at 1:55 AM Dave Brondsema >>> wrote: >>>> >>>>> Hi. >>>>> >>>>> On profile pages, the self.project refers to that user-project >>> /u/brondsem >>>>> for >>>>> example. You can get a reference to the same project in the dashboard >>> with >>>>> c.user.private_project() >>>>> >>>>> On another note, the title "My Followers" sounds like it would be >>> people >>>>> who >>>>> follow me, which isn't correct. On profile pages (if you click to view >>>>> all) it >>>>> says "Activity from people you follow" which is lengthy but better. Or >>>>> just >>>>> "Activity" would be ok. >>>>> >>>>> -Dave >>>>> >>>>> On 7/6/18 3:13 PM, Deshani Geethika wrote: >>>>>> Hi Dave, >>>>>> >>>>>> I've started to work on Followers Section and pushed the current code >>> to >>>>> my >>>>>> fork. ( >>>>> >>> https://forge-allura.apache.org/u/deshani/allura-personal-dashboard/ci/6522ff400387f1b1143d27cdd3afd1a63a811785/ >>>>>> ) >>>>>> >>>>>> I need to create activity_app instance in class FollowersSection in >>>>>> allura/ext/personal_dashboard/dashboard_main.py. (Line #163). >>>>>> >>>>>> In class ForgeActivityProfileSection which is in >>> forgeactivity/main.py, >>>>> the >>>>>> activity_app instance is created by accessing project instance as >>>>>> self.activity_app >&
[allura:tickets] #8216 Personal Dashboard - Create Activity Section
- **status**: open --> closed - **Reviewer**: Dave Brondsema - **Comment**: Merged with https://forge-allura.apache.org/p/allura/git/merge-requests/267/ --- ** [tickets:#8216] Personal Dashboard - Create Activity Section** **Status:** closed **Milestone:** unreleased **Labels:** Personal Dashboard **Created:** Fri Jul 06, 2018 06:52 PM UTC by Deshani **Last Updated:** Sun Jul 08, 2018 06:59 AM UTC **Owner:** Deshani --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8217 Content doesn't get saved when rate limit is hit
- **status**: in-progress --> review
- **Comment**:
Fixed on db/8217
Test with an absurd limit like: `forgediscussion.rate_limits_per_user =
{"4": 1}` and then create a discussion thread.
---
** [tickets:#8217] Content doesn't get saved when rate limit is hit**
**Status:** review
**Milestone:** unreleased
**Created:** Mon Jul 09, 2018 08:26 PM UTC by Dave Brondsema
**Last Updated:** Mon Jul 09, 2018 08:26 PM UTC
**Owner:** Dave Brondsema
When a rate limit is hit, our content-saving logic discards what was entered.
It shouldn't.
---
Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed
to https://forge-allura.apache.org/p/allura/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is
a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8217 Content doesn't get saved when rate limit is hit
--- ** [tickets:#8217] Content doesn't get saved when rate limit is hit** **Status:** in-progress **Milestone:** unreleased **Created:** Mon Jul 09, 2018 08:26 PM UTC by Dave Brondsema **Last Updated:** Mon Jul 09, 2018 08:26 PM UTC **Owner:** Dave Brondsema When a rate limit is hit, our content-saving logic discards what was entered. It shouldn't. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8213 Nested replies don't update ticket timestamp
- **status**: open --> review - **assigned_to**: Dave Brondsema - **Comment**: Forums show `Thread`'s `mod_date` (there is also a `last_post_date`) and that does get updated on top-level and nested replies. Tickets show the `mod_date`. Wiki pages shows (on the browse page) the last `Snapshot`'s `timestamp` so that doesn't update on comments at all, which is good since comments aren't as central to a wiki. Similar for blog posts (which only show a post date). Fixed on db/8213 QA: confirm that top-level & nested replies update timestamps as expected for each type of tool. --- ** [tickets:#8213] Nested replies don't update ticket timestamp** **Status:** review **Milestone:** unreleased **Created:** Thu Jun 28, 2018 04:53 PM UTC by Dave Brondsema **Last Updated:** Thu Jun 28, 2018 04:53 PM UTC **Owner:** Dave Brondsema Commenting on a ticket will update its "Updated" timestamp. But a nested reply to an existing comment on the ticket doesn't update that, which seems inconsistent. Might affect all threaded discussions, not just tickets. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8215 Personal Dashboard - Create Merge Requests Section NEEDS ENSURE_INDEX
- **summary**: Personal Dashboard - Create Merge Requests Section --> Personal Dashboard - Create Merge Requests Section NEEDS ENSURE_INDEX - **status**: in-progress --> closed - **Reviewer**: Dave Brondsema - **Comment**: Done in https://forge-allura.apache.org/p/allura/git/merge-requests/265/ This code adds a new index, so we need to add an `ensure_index` command to our release notes in next release. --- ** [tickets:#8215] Personal Dashboard - Create Merge Requests Section NEEDS ENSURE_INDEX** **Status:** closed **Milestone:** unreleased **Labels:** Personal Dashboard **Created:** Wed Jul 04, 2018 06:40 PM UTC by Deshani **Last Updated:** Wed Jul 04, 2018 06:40 PM UTC **Owner:** Deshani --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8209 Personal Dashboard - Create Tickets section
- **status**: in-progress --> closed - **Reviewer**: Dave Brondsema - **Comment**: Done in https://forge-allura.apache.org/p/allura/git/merge-requests/264/ --- ** [tickets:#8209] Personal Dashboard - Create Tickets section** **Status:** closed **Milestone:** unreleased **Labels:** Personal Dashboard **Created:** Wed Jun 20, 2018 07:38 PM UTC by Deshani **Last Updated:** Fri Jul 06, 2018 12:19 PM UTC **Owner:** Deshani --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8214 Compute merge request commits in background
- **status**: in-progress --> review - **Comment**: Done on db/8214 Note: when logged in as an admin, you'll see one-click merge button and the bg checks happening for that too. Doing a merge-request as a non-admin user will be a more common scenario. To simulate a very slow task, you can stop `taskd` processes before submitting the merge request, and then start them again a bit later. --- ** [tickets:#8214] Compute merge request commits in background** **Status:** review **Milestone:** unreleased **Labels:** performance **Created:** Fri Jun 29, 2018 08:56 PM UTC by Dave Brondsema **Last Updated:** Fri Jun 29, 2018 08:56 PM UTC **Owner:** Dave Brondsema We added caching to merge requests' list of commits previously (`allura.model.repository.MergeRequest#commits`). But it still can sometimes be slow the very first time. This is particularly a problem when creating the merge request and there's been no chance for it to get cached. * if 'commits' are available (cached), show them on the page just like we do now * if they aren't, return the page without them. * start a background task to get them * use ajax to fetch the bg tasks results when complete, and insert them into the page There is a similar pattern in place already for seeing if the commits are cleanly mergeable (see "merge_task_status") --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8214 Compute merge request commits in background
--- ** [tickets:#8214] Compute merge request commits in background** **Status:** in-progress **Milestone:** unreleased **Labels:** performance **Created:** Fri Jun 29, 2018 08:56 PM UTC by Dave Brondsema **Last Updated:** Fri Jun 29, 2018 08:56 PM UTC **Owner:** Dave Brondsema We added caching to merge requests' list of commits previously (`allura.model.repository.MergeRequest#commits`). But it still can sometimes be slow the very first time. This is particularly a problem when creating the merge request and there's been no chance for it to get cached. * if 'commits' are available (cached), show them on the page just like we do now * if they aren't, return the page without them. * start a background task to get them * use ajax to fetch the bg tasks results when complete, and insert them into the page There is a similar pattern in place already for seeing if the commits are cleanly mergeable (see "merge_task_status") --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8213 Nested replies don't update ticket timestamp
--- ** [tickets:#8213] Nested replies don't update ticket timestamp** **Status:** open **Milestone:** unreleased **Created:** Thu Jun 28, 2018 04:53 PM UTC by Dave Brondsema **Last Updated:** Thu Jun 28, 2018 04:53 PM UTC **Owner:** nobody Commenting on a ticket will update its "Updated" timestamp. But a nested reply to an existing comment on the ticket doesn't update that, which seems inconsistent. Might affect all threaded discussions, not just tickets. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8212 Github import error on deleted users
- **status**: open --> review - **Comment**: Fixed on branch db/8212 --- ** [tickets:#8212] Github import error on deleted users** **Status:** review **Milestone:** unreleased **Labels:** github import **Created:** Tue Jun 26, 2018 10:00 PM UTC by Dave Brondsema **Last Updated:** Tue Jun 26, 2018 10:00 PM UTC **Owner:** Dave Brondsema ``` Traceback (most recent call last): File "/var/local/allura/ForgeImporters/forgeimporters/base.py", line 131, in import_tool mount_point=mount_point, mount_label=mount_label, **kw) File "/var/local/allura/ForgeImporters/forgeimporters/github/tracker.py", line 137, in import_tool self.process_events(extractor, ticket, issue) File "/var/local/allura/ForgeImporters/forgeimporters/github/tracker.py", line 205, in process_events self.get_user_link(event['actor']['login'])) TypeError: 'NoneType' object has no attribute '__getitem__' ``` This occurs when a deleted-on-github user is involved in a thread. https://github.com/ampache/ampache/issues/1669 in this case --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8212 Github import error on deleted users
--- ** [tickets:#8212] Github import error on deleted users** **Status:** open **Milestone:** unreleased **Labels:** github import **Created:** Tue Jun 26, 2018 10:00 PM UTC by Dave Brondsema **Last Updated:** Tue Jun 26, 2018 10:00 PM UTC **Owner:** Dave Brondsema ``` Traceback (most recent call last): File "/var/local/allura/ForgeImporters/forgeimporters/base.py", line 131, in import_tool mount_point=mount_point, mount_label=mount_label, **kw) File "/var/local/allura/ForgeImporters/forgeimporters/github/tracker.py", line 137, in import_tool self.process_events(extractor, ticket, issue) File "/var/local/allura/ForgeImporters/forgeimporters/github/tracker.py", line 205, in process_events self.get_user_link(event['actor']['login'])) TypeError: 'NoneType' object has no attribute '__getitem__' ``` This occurs when a deleted-on-github user is involved in a thread. https://github.com/ampache/ampache/issues/1669 in this case --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8210 Use different tmp dir for code snapshots
- **status**: in-progress --> review - **Comment**: Done on branch db/8210 and also on forgehg:db/8210 --- ** [tickets:#8210] Use different tmp dir for code snapshots** **Status:** review **Milestone:** unreleased **Created:** Thu Jun 21, 2018 08:08 PM UTC by Dave Brondsema **Last Updated:** Thu Jun 21, 2018 08:08 PM UTC **Owner:** Dave Brondsema For code snapshots, we should support a config option to have the temporary checkout directory be different than where the final zip file resides. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8210 Use different tmp dir for code snapshots
--- ** [tickets:#8210] Use different tmp dir for code snapshots** **Status:** in-progress **Milestone:** unreleased **Created:** Thu Jun 21, 2018 08:08 PM UTC by Dave Brondsema **Last Updated:** Thu Jun 21, 2018 08:08 PM UTC **Owner:** Dave Brondsema For code snapshots, we should support a config option to have the temporary checkout directory be different than where the final zip file resides. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Re: [GSoC] [COMDEV-254] Allura - Personal Dashboard
Sounds good, pagination is definitely important if people have a lot of tickets.
In the ForgeTracker tool forgetracker/model/ticket.py there are methods
paged_search() and paged_query() which might be good reference points. It looks
like they probably can't be re-used directly, since they expect an app_config,
and the dashboard will search across all ticket tracker apps. It also supports
filtering and search terms that aren't needed. But it might be useful.
There's other things in the ForgeTracker that might be useful too. Like listing
the results with the TicketSearchResults class and ticket_search_results.html
template. Again, those have things like filtering, configurable columns, etc
that aren't necessary on the dashboard. But it could be a good reference for
how paging is used, etc.
I would recommend using a solr search rather than a mongo query to find the
tickets. That is because the Ticket class does not have a mongo index for the
submitter, and so querying by submitter could be very slow when there are
thousands and thousands of tickets. Searching with solr also would also let us
support people filtering & searching their own tickets list, in the future if we
wanted to do that (not necessary this summer).
On 6/21/18 12:11 PM, Deshani Geethika wrote:
> Hi Dave,
>
> Currently I'm working on creating "Tickets Section" of Dashboard. I have
> implemented to load all of the tickets at once, but I thought to paginate
> this and I'm working on it.
>
> Will give you an update soon. If you have any suggestions please let me
> know.
>
> Regards!
>
> On Thu, Jun 14, 2018 at 12:22 AM Deshani Geethika
> wrote:
>
>> Hi Dave,
>>
>> Thanks for reviewing and merging the above requests.
>>
>> I've created a helper method to avoid code duplication in
>> DashboardController.index and UserProfileApp.profile_sections, and added a
>> merge
>> request <https://forge-allura.apache.org/p/allura/git/merge-requests/259/>
>> .
>>
>> Please review it and let me know if any improvements required.
>>
>> Regards!
>>
>> On Tue, Jun 12, 2018 at 1:20 AM Deshani Geethika <
>> deshanigeeth...@gmail.com> wrote:
>>
>>> Hi Dave,
>>>
>>> I've updated the above merge request
>>> <https://forge-allura.apache.org/p/allura/git/merge-requests/255/>, as
>>> I've fixed an issue in a template.
>>>
>>> Meanwhile, I started a new branch for dashboard tests and added a simple
>>> test to check '/dashboard' route. I've created a new merge request
>>> <https://forge-allura.apache.org/p/allura/git/merge-requests/258/> for
>>> this. Please review it and let me know if any improvements required.
>>>
>>> Regards!
>>>
>>> On Sat, Jun 9, 2018 at 12:07 PM Deshani Geethika <
>>> deshanigeeth...@gmail.com> wrote:
>>>
>>>> Hi Dave,
>>>>
>>>> Thanks for the clarifications :)
>>>>
>>>> I've fixed the issues with test cases and updated the merge request
>>>> <https://forge-allura.apache.org/p/allura/git/merge-requests/255/>.
>>>> Please review it and let me know if any improvements required
>>>>
>>>> Regards!
>>>>
>>>> On Wed, Jun 6, 2018 at 8:56 PM Dave Brondsema
>>>> wrote:
>>>>
>>>>> On 6/6/18 5:37 AM, Deshani Geethika wrote:
>>>>>> Hi Dave,
>>>>>>
>>>>>> I need some help in understanding an error related to test cases.
>>>>>>
>>>>>> I was trying to write a test case to check the '/neighborhood' route
>>>>> in
>>>>>> Allura/allura/tests/functional/test_root.py as below.
>>>>>>
>>>>>> def test_neighborhood(self):
>>>>>>> response = self.app.get('/neighborhood/')
>>>>>>
>>>>>>
>>>>>> But I get the following error, when I run the above test case.
>>>>>>
>>>>>> Traceback (most recent call last):
>>>>>>> File
>>>>>>>
>>>>> "/home/deshani/env-allura/local/lib/python2.7/site-packages/nose/case.py",
>>>>>>> line 197, in runTest
>>>>>>> self.test(*self.arg)
>>>>>>> File
>>>>>>>
>>>>> "/home/deshani/src/allura/Allura/allura/tests/functional/test_root.py",
>>>>>>> line 58, in test_neighborhood
>>>>>>> response = self.app.get('/neighborhood/
[allura:tickets] #8208 Personal Dashboard - Create Projects section
- **status**: in-progress --> closed - **Reviewer**: Dave Brondsema - **Comment**: Merged at https://forge-allura.apache.org/p/allura/git/merge-requests/262/ --- ** [tickets:#8208] Personal Dashboard - Create Projects section** **Status:** closed **Milestone:** unreleased **Labels:** Personal Dashboard **Created:** Sun Jun 17, 2018 05:03 PM UTC by Deshani **Last Updated:** Sun Jun 17, 2018 05:04 PM UTC **Owner:** Deshani Implement the Projects section of Dashboard --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8207 Personal Dashboard - Add parent class for ProfileSectionBase and DashboardSectionBase
- **status**: open --> closed - **Reviewer**: Dave Brondsema - **Comment**: Nice! --- ** [tickets:#8207] Personal Dashboard - Add parent class for ProfileSectionBase and DashboardSectionBase ** **Status:** closed **Milestone:** unreleased **Labels:** Personal Dashboard **Created:** Fri Jun 15, 2018 06:53 PM UTC by Deshani **Last Updated:** Fri Jun 15, 2018 06:53 PM UTC **Owner:** Deshani To avoid code duplication in ProfileSectionBase and DashboardSectionBase, parent class is added. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] Re: #8204 Create new neighbourhood
Everything is saved to mongodb, so restarts wont' lose anything. With the docker setup, you can restart with: `docker-compose restart taskd` and `docker-compose restart web` With step-by-step installation you basically just stop the process and then start it again. (In a production-ready setup you'd want to create a service to manage it). So something like: * `pkill -f gunicorn` and then `gunicorn --reload --paste development.ini` again * `pkill "^taskd";` and then `nohup paster taskd development.ini >> /var/log/allura/taskd.log 2>&1 &` again --- ** [tickets:#8204] Create new neighbourhood** **Status:** open **Milestone:** unreleased **Created:** Fri Jun 08, 2018 06:15 AM UTC by Vrinda **Last Updated:** Fri Jun 15, 2018 12:06 PM UTC **Owner:** nobody Hello, I understand neighbourhoods can be used for grouping similar projects. By default I can see 3 neighbourhoods created by default : Adobe, Projects and Users. Is it possible to create new neighbourhood? Regards, Vrinda. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] Re: #8204 Create new neighbourhood
Yep, that is the error. You will need to set permissions so the allura webapp and taskd processes can read & write to that directory. Or change that directory with the `scm.repos.root` setting and `scm.host.file.git` setting in the `.ini` config file (and restart services). You'll probably want to make a new code repo after that, to make sure it gets initialized correctly. And then you should do a checkout of the repo, not commit directly in the /srv/git path. --- ** [tickets:#8204] Create new neighbourhood** **Status:** open **Milestone:** unreleased **Created:** Fri Jun 08, 2018 06:15 AM UTC by Vrinda **Last Updated:** Thu Jun 14, 2018 03:19 AM UTC **Owner:** nobody Hello, I understand neighbourhoods can be used for grouping similar projects. By default I can see 3 neighbourhoods created by default : Adobe, Projects and Users. Is it possible to create new neighbourhood? Regards, Vrinda. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8206 Personal Dashboard - Add helper method to load sections of Dashboard and Profile
- **status**: open --> closed - **Reviewer**: Dave Brondsema - **Comment**: Merged in https://forge-allura.apache.org/p/allura/git/merge-requests/259/ --- ** [tickets:#8206] Personal Dashboard - Add helper method to load sections of Dashboard and Profile** **Status:** closed **Milestone:** unreleased **Labels:** Personal Dashboard **Created:** Wed Jun 13, 2018 06:32 PM UTC by Deshani **Last Updated:** Wed Jun 13, 2018 06:32 PM UTC **Owner:** Deshani A helper method to avoid code duplication in DashboardController.index and UserProfileApp.profile_sections --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] Re: #8204 Create new neighbourhood
Is the `taskd` process running? That is an allura command that runs background processes like initializing repositories. With the docker setup it is just one of the containers. If you are running without docker, https://forge-allura.apache.org/docs/getting_started/install_each_step.html#allura-task-processing has the basic command to run it. --- ** [tickets:#8204] Create new neighbourhood** **Status:** open **Milestone:** unreleased **Created:** Fri Jun 08, 2018 06:15 AM UTC by Vrinda **Last Updated:** Wed Jun 13, 2018 11:19 AM UTC **Owner:** nobody Hello, I understand neighbourhoods can be used for grouping similar projects. By default I can see 3 neighbourhoods created by default : Adobe, Projects and Users. Is it possible to create new neighbourhood? Regards, Vrinda. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] Re: #8204 Create new neighbourhood
There's not exactly a way to delete a neighborhood, but you can create the initial database without the example neighborhoods. See the `setup-app` note at https://forge-allura.apache.org/docs/getting_started/installation.html Otherwise you can go into the mongodb shell to remove things, see: https://www.mail-archive.com/allura-dev@incubator.apache.org/msg02260.html You could modify the `templates/neighborhood_list.html` file directly. A little cleaner but more work is to make a new python package and set up template overrides. Docs for that are at https://forge-allura.apache.org/docs/api/lib/package_path_loader.html#overriding-dotted-notation And yes, evicting is meant to send a project to the "Projects" neighborhood. The Projects neighborhood is the main default neighborhood. --- ** [tickets:#8204] Create new neighbourhood** **Status:** open **Milestone:** unreleased **Created:** Fri Jun 08, 2018 06:15 AM UTC by Vrinda **Last Updated:** Mon Jun 11, 2018 08:41 AM UTC **Owner:** nobody Hello, I understand neighbourhoods can be used for grouping similar projects. By default I can see 3 neighbourhoods created by default : Adobe, Projects and Users. Is it possible to create new neighbourhood? Regards, Vrinda. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #6070 Make code snapshots based on directory
- **status**: in-progress --> closed --- ** [tickets:#6070] Make code snapshots based on directory** **Status:** closed **Milestone:** unreleased **Labels:** code-snapshots **Created:** Mon Apr 08, 2013 06:22 PM UTC by Dave Brondsema **Last Updated:** Mon Jun 11, 2018 03:17 PM UTC **Owner:** Dave Brondsema It'd be nice to make code snapshots for the given path instead of the whole directory. This is *especially* true of SVN where you'd want a snapshot of trunk but not all the branches & tags directories. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8205 Personal Dashboard - Add test functionality for Dashboard basics
- **status**: open --> closed - **Reviewer**: Dave Brondsema --- ** [tickets:#8205] Personal Dashboard - Add test functionality for Dashboard basics** **Status:** closed **Milestone:** unreleased **Labels:** Personal Dashboard **Created:** Mon Jun 11, 2018 07:23 PM UTC by Deshani **Last Updated:** Mon Jun 11, 2018 07:23 PM UTC **Owner:** Deshani Adds test functionality to check the '/dashboard' route. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8202 Personal Dashboard - Creating basics of Dashboard (Creating file structure, defining routes and loading sections to main UI)
- **status**: open --> closed - **Reviewer**: Dave Brondsema --- ** [tickets:#8202] Personal Dashboard - Creating basics of Dashboard (Creating file structure, defining routes and loading sections to main UI)** **Status:** closed **Milestone:** unreleased **Labels:** Personal Dashboard **Created:** Mon May 28, 2018 08:18 AM UTC by Deshani **Last Updated:** Mon May 28, 2018 08:18 AM UTC **Owner:** Deshani In this ticket following features are created. 1. Creating the folder and file structure 2. Creating separate routes for ‘neighborhood’ and ‘dashboard’. Here when a user logged in, redirected to Dashboard (‘/dashboard’). If not logged in, redirected to Neighborhood (‘/neighborhood’). However, I didn’t block ‘/neighborhood’ route for a logged in user. (That means by default, when the user is logged in, Dashboard (‘/dashboard’) will be the landing page. Also, he can call Neighborhood route (‘/neighborhood’) manually) 3. Loading sections (eg: ProjectsSection, TicketsSection etc.) to the main UI. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #6070 Make code snapshots based on directory
--- ** [tickets:#6070] Make code snapshots based on directory** **Status:** in-progress **Milestone:** unreleased **Labels:** code-snapshots **Created:** Mon Apr 08, 2013 06:22 PM UTC by Dave Brondsema **Last Updated:** Wed Apr 15, 2015 01:25 PM UTC **Owner:** Dave Brondsema It'd be nice to make code snapshots for the given path instead of the whole directory. This is *especially* true of SVN where you'd want a snapshot of trunk but not all the branches & tags directories. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] Ticket 6070 discussion
- **status**: open --> in-progress - **assigned_to**: Dave Brondsema --- ** [tickets:#6070] Make code snapshots based on directory** **Status:** in-progress **Milestone:** unreleased **Labels:** code-snapshots **Created:** Mon Apr 08, 2013 06:22 PM UTC by Dave Brondsema **Last Updated:** Wed Apr 15, 2015 01:25 PM UTC **Owner:** Dave Brondsema It'd be nice to make code snapshots for the given path instead of the whole directory. This is *especially* true of SVN where you'd want a snapshot of trunk but not all the branches & tags directories. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8204 Create new neighbourhood
Yes, you can create more neighborhoods with the `create-neighborhood` command. https://forge-allura.apache.org/docs/getting_started/administration.html The Clustering, etc categories on the home page are not used by anything any more, and are due for removal. Most Allura instances customize their index page. The Evict option under neighborhood moderation is not a commonly used feature, but I tested it just now and it worked fine. If you still get that error, can you provide more details about the steps you took, which project and neighborhood, etc? --- ** [tickets:#8204] Create new neighbourhood** **Status:** open **Milestone:** unreleased **Created:** Fri Jun 08, 2018 06:15 AM UTC by Vrinda **Last Updated:** Fri Jun 08, 2018 10:58 AM UTC **Owner:** nobody Hello, I understand neighbourhoods can be used for grouping similar projects. By default I can see 3 neighbourhoods created by default : Adobe, Projects and Users. Is it possible to create new neighbourhood? Regards, Vrinda. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Re: [GSoC] [COMDEV-254] Allura - Personal Dashboard
On 6/6/18 5:37 AM, Deshani Geethika wrote:
> Hi Dave,
>
> I need some help in understanding an error related to test cases.
>
> I was trying to write a test case to check the '/neighborhood' route in
> Allura/allura/tests/functional/test_root.py as below.
>
> def test_neighborhood(self):
>> response = self.app.get('/neighborhood/')
>
>
> But I get the following error, when I run the above test case.
>
> Traceback (most recent call last):
>> File
>> "/home/deshani/env-allura/local/lib/python2.7/site-packages/nose/case.py",
>> line 197, in runTest
>> self.test(*self.arg)
>> File
>> "/home/deshani/src/allura/Allura/allura/tests/functional/test_root.py",
>> line 58, in test_neighborhood
>> response = self.app.get('/neighborhood/')
>> File "/home/deshani/src/allura/AlluraTest/alluratest/validation.py",
>> line 322, in get
>> resp = super(ValidatingTestApp, self).get(*args, **kw)
>> File "/home/deshani/src/allura/AlluraTest/alluratest/validation.py",
>> line 269, in get
>> return super(PostParamCheckingTestApp, self).get(*args, **kwargs)
>> File
>> "/home/deshani/env-allura/local/lib/python2.7/site-packages/webtest/app.py",
>> line 756, in get
>> expect_errors=expect_errors)
>> File
>> "/home/deshani/env-allura/local/lib/python2.7/site-packages/webtest/app.py",
>> line 1118, in do_request
>> self._check_status(status, res)
>> File
>> "/home/deshani/env-allura/local/lib/python2.7/site-packages/webtest/app.py",
>> line 1154, in _check_status
>> res)
>> AppError: Bad response: 404 Not Found (not 200 OK or 3xx redirect for
>> http://localhost/neighborhood/)
>
>
> Can you help me to understand why this error comes up?
>
> Regards!
Wow, this was a tricky one! I was stumped about this for a while too. Its
happening because of some helper code for tests, that is not very obvious. In
Allura/allura/controllers/basetest_project_root.py a modified root controller is
used for tests, which makes some project & tool testing easier. This controller
is used because test.ini specifies "override_root=basetest_project_root"
And then in this controller on line 71 there is a list of root controller
attributes that is hardcoded. So you will have to add 'neighborhood' and
'dashboard' to that list.
I would also recommend adding a comment on the real RootController mentioning
the BasetestProjectRootController so that anyone else in the future who adds a
root url knows that they have to update the other place too.
--
Dave Brondsema : d...@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
<><
[allura:tickets] Re: #8203 Download button for a project
It doesn't look like the markdown converter handles file:// links, sorry. For security reasons I think both markdown and some browsers put restrictions on using file:// links. You'll have to put the file on your webserver and have the webserver serve it (or try attaching it to a wiki page, etc, within Allura) --- ** [tickets:#8203] Download button for a project** **Status:** open **Milestone:** unreleased **Created:** Tue Jun 05, 2018 11:59 AM UTC by Vrinda **Last Updated:** Wed Jun 06, 2018 06:58 AM UTC **Owner:** nobody I am new to Apache Allura and am trying to set it up locally to host a few projects. I have installed Allura platform on Ubuntu 16.04 by following the installation guide: https://forge-allura.apache.org/docs/getting_started/install_each_step.html I could get the application server running and I am now able to create a new project. How do I create the 'Download' button using which I want to allow downloading of the executable of the project? In the feature list : https://forge-allura.apache.org/p/allura/wiki/Features/, I can see under Documentation that this is possible using custom wiki macros?? How can I do this? --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Small wording improvement
I've received feedback that the following wording can be quite scary and concerning. It shows up on repo pages when new code is pushed but Allura's metadata for it isn't present yet. The metadata for this repository is missing. To fix, please try a Repository Refresh. I'm thinking of updating it to something like this. Any ideas for even better wording? Browsing this repo on the web is unavailable currently. To fix, please try a Repository Refresh. Committing and pulling code should still work. -- Dave Brondsema : d...@brondsema.net http://www.brondsema.net : personal http://www.splike.com : programming <><
Re: [GSoC] [COMDEV-254] Allura - Personal Dashboard
On 5/28/18 4:12 AM, Deshani Geethika wrote: > Hi Dave, > > During last week I focused on learning frameworks and basics related to > Allura and now I’m ready to add the first merge request of Personal > Dashboard. When adding the merge request, should it be added to the master > branch of the remote? > > Regards! > I would recommend making a new branch for each task you work on. That way you can have multiple going at the same time, if they are not dependent on each other. That will also let you keep master in sync with upstream master, and not have local changes in it. -- Dave Brondsema : d...@brondsema.net http://www.brondsema.net : personal http://www.splike.com : programming <><
Re: Indexing source code
On 5/23/18 2:01 PM, Ingo Hornberger wrote: > Hi folks! > > I searched already quite a bit through the code. But to be honest I don't > fully understand the allura concept for managing the solr index, yet. > > My goal is to be able to search for code and markdown files in > repositories. The global search should simply also match source code. > > Has anybody an idea how to implement that? > > BR, > Ingo > Hi Ingo! Here's the key parts: SearchIndexable is a mixin class that everything indexing into solr should use. Examples are Users, Projects, and all the Artifact child classes (wiki pages, comments, etc, etc). It has an index() method with a docstring to explain it, and you can look at other index examples for reference. All the things that use the SearchIndexable mixin currently are models that get saved to mongo, via ming. That happens automatically through ming extensions: IndexerSessionExtension (for users & projects) and ArtifactSessionExtension (for artifacts). Those run automatically whenever models are saved with a change. They end up calling add_artifacts() and similar tasks in the allura.tasks.index_tasks package. And those call index() methods and save to solr. For files in code repositories, the ming extensions won't work since code repos' files aren't Ming models stored in mongo. But you can still make a class that uses the SearchIndexable mixin. And still use methods similar to allura.tasks.index_tasks to do the indexing. You'll just need to set up something different to go through the repos or respond to new commits (e.g. allura.model.repo_refresh:refresh_repo) and trigger the index task. Hope that helps point you in a good direction. It would be a great feature indeed! -- Dave Brondsema : d...@brondsema.net http://www.brondsema.net : personal http://www.splike.com : programming <><
Re: [GSoC] [COMDEV-254] Allura - Personal Dashboard
That works, and so does google hangouts. See you then On 5/17/18 2:17 PM, Deshani Geethika wrote: > Thanks. Can we make it tomorrow (18th May) 10am ET? or any other convenient > time of your choice. > > Is it a Hangouts call? or please let me know if I need to setup any other > application > > Regards! > > On Thu, May 17, 2018 at 8:57 PM, Dave Brondsema <d...@brondsema.net> wrote: > >> Sure. I am available 10am-6pm ET on weekdays, and also Sat/Sun could be >> available 12pm - 10pm. >> https://www.timeanddate.com/worldclock/converter.html?p1=tz_ist=tz_et >> >> On 5/17/18 7:10 AM, Deshani Geethika wrote: >>> Hi Dave, >>> >>> To get an overview about Allura code-base and conventions, it would be >>> great if we can arrange a call. Could you tell me your available time >> slots >>> for a meeting. >>> My time zone is IST (+0530). >>> >>> Regards! >>> >>> On Mon, May 14, 2018 at 9:44 PM, Dave Brondsema <d...@brondsema.net> >> wrote: >>> >>>> Hi, >>>> >>>> Allura can be pretty flexible, but in general we follow these >> conventions: >>>> >>>> Core components that are deeply integrated into allura go in the >>>> Allura/allura/model & controllers directories. >>>> >>>> Non-essential components go in the Allura/allura/ext/ directory. Like >>>> "extra" >>>> or "extensions". So this would make sense for the personal dashboard I >>>> think. >>>> >>>> Standalone components that can be their application go in ForgeBlog, >>>> ForgeChat, >>>> etc. as separate python packages. >>>> >>>> -Dave >>>> >>>> On 5/14/18 9:44 AM, Deshani Geethika wrote: >>>>> Hi Dave, >>>>> >>>>> During last few days I was working on my GSoC project and I have few >>>>> problems to be clarified. >>>>> >>>>> In my proposal >>>>> <https://docs.google.com/document/d/1clWKSJ8- >>>> ektpVaEgiJyoM34ievwkyCnD4uORMCT0eM8/edit?usp=sharing> >>>>> I have mentioned that, personal_dashboard folder should be created on >> the >>>>> path Allura/allura/ext/personal_dashboard. But, I have a confusion >>>> whether >>>>> this path is correct, since the Personal Dashboard is not an >> application. >>>>> >>>>> Therefore, I have followed the neighborhood implementation and found >> out >>>>> that its templates are in the path Allura/allura/templates. Also, its >>>>> implementation (neighborhood.py) is in the path >>>>> Allura/allura/model/neighborhood.py. >>>>> >>>>> From above two paths, what is the correct convention that I should >>>> follow? >>>>> >>>>> Regards! >>>>> >>>>> On Thu, May 3, 2018 at 3:21 AM, Dave Brondsema <d...@brondsema.net> >>>> wrote: >>>>> >>>>>> On 5/2/18 11:24 AM, Deshani Geethika wrote: >>>>>>> Hi Dave, >>>>>>> >>>>>>> Thanks for the information. I have few questions to be clarified. >>>>>>> >>>>>>> I think replacing spaces with underscores would be a good way to do >> it, >>>>>>> since on many wikis they are >>>>>>> interchangable. (They aren't for allura, but we could move towards >>>>>> that). >>>>>>> >>>>>>> Here do you mean that spaces and underscores in a title are >> considered >>>> as >>>>>>> same characters? >>>>>>> >>>>>>> For example : "The Title" is considered same as "The_Title". >>>>>> >>>>>> Yes that's what I was thinking. >>>>>> >>>>>>> >>>>>>> In this situation, users should not be allowed to create 2 wikis with >>>>>> above >>>>>>> titles, because we can't handle inbound emails for both scenarios. >>>>>> >>>>>> Good point, I hadn't thought of that. That does make this more >>>>>> complicated. >>>>>> Maybe it could be a followup step to prevent creating a page that >>>>>> conflicts with >>>>>> another one. And then
Re: [GSoC] [COMDEV-254] Allura - Personal Dashboard
Sure. I am available 10am-6pm ET on weekdays, and also Sat/Sun could be available 12pm - 10pm. https://www.timeanddate.com/worldclock/converter.html?p1=tz_ist=tz_et On 5/17/18 7:10 AM, Deshani Geethika wrote: > Hi Dave, > > To get an overview about Allura code-base and conventions, it would be > great if we can arrange a call. Could you tell me your available time slots > for a meeting. > My time zone is IST (+0530). > > Regards! > > On Mon, May 14, 2018 at 9:44 PM, Dave Brondsema <d...@brondsema.net> wrote: > >> Hi, >> >> Allura can be pretty flexible, but in general we follow these conventions: >> >> Core components that are deeply integrated into allura go in the >> Allura/allura/model & controllers directories. >> >> Non-essential components go in the Allura/allura/ext/ directory. Like >> "extra" >> or "extensions". So this would make sense for the personal dashboard I >> think. >> >> Standalone components that can be their application go in ForgeBlog, >> ForgeChat, >> etc. as separate python packages. >> >> -Dave >> >> On 5/14/18 9:44 AM, Deshani Geethika wrote: >>> Hi Dave, >>> >>> During last few days I was working on my GSoC project and I have few >>> problems to be clarified. >>> >>> In my proposal >>> <https://docs.google.com/document/d/1clWKSJ8- >> ektpVaEgiJyoM34ievwkyCnD4uORMCT0eM8/edit?usp=sharing> >>> I have mentioned that, personal_dashboard folder should be created on the >>> path Allura/allura/ext/personal_dashboard. But, I have a confusion >> whether >>> this path is correct, since the Personal Dashboard is not an application. >>> >>> Therefore, I have followed the neighborhood implementation and found out >>> that its templates are in the path Allura/allura/templates. Also, its >>> implementation (neighborhood.py) is in the path >>> Allura/allura/model/neighborhood.py. >>> >>> From above two paths, what is the correct convention that I should >> follow? >>> >>> Regards! >>> >>> On Thu, May 3, 2018 at 3:21 AM, Dave Brondsema <d...@brondsema.net> >> wrote: >>> >>>> On 5/2/18 11:24 AM, Deshani Geethika wrote: >>>>> Hi Dave, >>>>> >>>>> Thanks for the information. I have few questions to be clarified. >>>>> >>>>> I think replacing spaces with underscores would be a good way to do it, >>>>> since on many wikis they are >>>>> interchangable. (They aren't for allura, but we could move towards >>>> that). >>>>> >>>>> Here do you mean that spaces and underscores in a title are considered >> as >>>>> same characters? >>>>> >>>>> For example : "The Title" is considered same as "The_Title". >>>> >>>> Yes that's what I was thinking. >>>> >>>>> >>>>> In this situation, users should not be allowed to create 2 wikis with >>>> above >>>>> titles, because we can't handle inbound emails for both scenarios. >>>> >>>> Good point, I hadn't thought of that. That does make this more >>>> complicated. >>>> Maybe it could be a followup step to prevent creating a page that >>>> conflicts with >>>> another one. And then even later on we could make URLs handle spaces >> and >>>> underscores interchangably. >>>> >>>> Anyone else have ideas about what would be best? >>>> >>>>> >>>>> Also, we have another problem here. >>>>> >>>>> Then this handle_message method could try finding a page for that >>>> message, >>>>> and if it >>>>> doesn't exist, it can convert any underscores back to spaces and then >> try >>>>> find >>>>> the wiki page under that name. >>>>> >>>>> Here do I need to check for all the possible number of combinations of >>>>> underscores and spaces to find out the exact wiki page? >>>> >>>> >>>> I was thinking if an email comes in for "Foo_Bar_Baz" first look for one >>>> titled >>>> "Foo_Bar_Baz" and then one titled "Foo Bar Baz". Trying every >> combination >>>> could >>>> get crazy. >>>> >>>>> >>>>> Reg
Re: [GSoC] [COMDEV-254] Allura - Personal Dashboard
Hi, Allura can be pretty flexible, but in general we follow these conventions: Core components that are deeply integrated into allura go in the Allura/allura/model & controllers directories. Non-essential components go in the Allura/allura/ext/ directory. Like "extra" or "extensions". So this would make sense for the personal dashboard I think. Standalone components that can be their application go in ForgeBlog, ForgeChat, etc. as separate python packages. -Dave On 5/14/18 9:44 AM, Deshani Geethika wrote: > Hi Dave, > > During last few days I was working on my GSoC project and I have few > problems to be clarified. > > In my proposal > <https://docs.google.com/document/d/1clWKSJ8-ektpVaEgiJyoM34ievwkyCnD4uORMCT0eM8/edit?usp=sharing> > I have mentioned that, personal_dashboard folder should be created on the > path Allura/allura/ext/personal_dashboard. But, I have a confusion whether > this path is correct, since the Personal Dashboard is not an application. > > Therefore, I have followed the neighborhood implementation and found out > that its templates are in the path Allura/allura/templates. Also, its > implementation (neighborhood.py) is in the path > Allura/allura/model/neighborhood.py. > > From above two paths, what is the correct convention that I should follow? > > Regards! > > On Thu, May 3, 2018 at 3:21 AM, Dave Brondsema <d...@brondsema.net> wrote: > >> On 5/2/18 11:24 AM, Deshani Geethika wrote: >>> Hi Dave, >>> >>> Thanks for the information. I have few questions to be clarified. >>> >>> I think replacing spaces with underscores would be a good way to do it, >>> since on many wikis they are >>> interchangable. (They aren't for allura, but we could move towards >> that). >>> >>> Here do you mean that spaces and underscores in a title are considered as >>> same characters? >>> >>> For example : "The Title" is considered same as "The_Title". >> >> Yes that's what I was thinking. >> >>> >>> In this situation, users should not be allowed to create 2 wikis with >> above >>> titles, because we can't handle inbound emails for both scenarios. >> >> Good point, I hadn't thought of that. That does make this more >> complicated. >> Maybe it could be a followup step to prevent creating a page that >> conflicts with >> another one. And then even later on we could make URLs handle spaces and >> underscores interchangably. >> >> Anyone else have ideas about what would be best? >> >>> >>> Also, we have another problem here. >>> >>> Then this handle_message method could try finding a page for that >> message, >>> and if it >>> doesn't exist, it can convert any underscores back to spaces and then try >>> find >>> the wiki page under that name. >>> >>> Here do I need to check for all the possible number of combinations of >>> underscores and spaces to find out the exact wiki page? >> >> >> I was thinking if an email comes in for "Foo_Bar_Baz" first look for one >> titled >> "Foo_Bar_Baz" and then one titled "Foo Bar Baz". Trying every combination >> could >> get crazy. >> >>> >>> Regards! >>> >>> >>> >>> On Wed, May 2, 2018 at 7:17 AM, Dave Brondsema <d...@brondsema.net> >> wrote: >>> >>>> Cool. That email_address property should be the main one and changing >> it >>>> should >>>> reflect in the outgoing emails that are sent to subscribers after >>>> commenting or >>>> editing a wiki page. >>>> >>>> Allura also supports *inbound* emails on most artifacts including wiki >>>> pages. >>>> So someone could reply to the wiki email and it would be received by >>>> Allura and >>>> added as a comment on the wiki page. The >>>> forgewiki.wiki_main.ForgeWikiApp#handle_message method is what is >>>> responsible >>>> for that. So that code should be updated as well. I think replacing >>>> spaces >>>> with underscores would be a good way to do it, since on many wikis they >> are >>>> interchangable. (They aren't for allura, but we could move towards >>>> that). Then >>>> this handle_message method could try finding a page for that message, >> and >>>> if it >>>> doesn't exist, it can convert any underscores back to spaces and then >
Re: #1699 Fix incoming email for wiki pages with space in the title
Hi Deshani,
I merged the request already, but have now realized I didn't test it thoroughly
enough. In the email_address property, self.title.replace(' ', '_') doesn't do
anything on its own. It needs to be saved to a variable and use that, or
chained onto the existing replace('/', '.')
Want to make another merge request?
Thanks!
On 5/7/18 6:07 PM, Dave Brondsema wrote:
> Sorry for the delays, I will try to get this tomorrow and post feedback on the
> merge request tomorrow.
>
> This is a good opportunity to say that delays and time to discuss & coordinate
> are inevitable. Its a good reason to keep units of work small enough, and
> during "fulltime" work on Allura expect to switch gears to a different tasks
> on
> different branches while waiting for feedback.
>
> Thanks though and hope to post feedback tomorrow!
>
> On 5/4/18 3:47 PM, Deshani Geethika wrote:
>> Hi Dave,
>>
>> I've fixed the issue and added a merge request
>> <https://forge-allura.apache.org/p/allura/git/merge-requests/252/>.
>>
>> Please review it and let me know any improvements.
>>
>> Regards!
>>
>> On Fri, May 4, 2018 at 3:13 AM, Dave Brondsema <d...@brondsema.net> wrote:
>>
>>> I think this method, handling inbound emails to wiki pages, is probably
>>> not used
>>> very much :) I haven't tried it but it does seem like that would let
>>> people
>>> create new wiki pages just by emailing to the address.
>>>
>>> 1) We probably don't need to allow that. Just allow emails to make
>>> comments on
>>> *existing* wiki pages (which I believe handle_artifact_message does)
>>>
>>> 2) If you look at `git blame` for handle_message you can see that it is
>>> quite
>>> old. Some of the very early work on Allura doesn't make perfect sense any
>>> more.
>>> So in this case it probably would be fine to remove the try/except since
>>> as you
>>> say upsert() shouldn't raise any exception. And I don't think the
>>> underlying
>>> get() and upsert() calls within upsert() would raise any either.
>>>
>>> -Dave
>>>
>>> On 5/3/18 11:20 AM, Deshani Geethika wrote:
>>>> Hi Dave,
>>>>
>>>> Let's continue the discussion related to the above issue in this thread.
>>>>
>>>> I have few confusions on the forgewiki.wiki_main.
>>> ForgeWikiApp#handle_message
>>>> *[1]* method. Inside this method, Page.upsert method *[2]* is called, and
>>>> upsert method will update page with 'title' or insert new page with that
>>>> name. Does that means, if somebody sends an email to 'Foo_Baz@123' and
>>> if
>>>> that page is not available, a new page with the title 'Foo_Baz' will be
>>>> created? If so, we have some problems.
>>>>
>>>>1. We can't validate the title
>>>>2. 'upsert' method will never throw an exception (But in
>>> handle_message
>>>>method exception is handled)
>>>>
>>>>
>>>> *[1]*def handle_message(self, topic, message):
>>>> log.info('Message from %s (%s)',
>>>> topic, self.config.options.mount_point)
>>>> log.info('Headers are: %s', message['headers'])
>>>> try:
>>>> page = WM.Page.upsert(topic)
>>>> except:
>>>> log.exception('Error getting artifact %s', topic)
>>>> self.handle_artifact_message(page, message)
>>>>
>>>> *[2]* @classmethod
>>>> def upsert(cls, title, version=None):
>>>> """Update page with `title` or insert new page with that name"""
>>>> if version is None:
>>>> # Check for existing page object
>>>> obj = cls.query.get(
>>>> app_config_id=context.app.config._id,
>>>> title=title)
>>>> if obj is None:
>>>> obj = cls(
>>>> title=title,
>>>> app_config_id=context.app.config._id,
>>>> )
>>>> Thread.new(discussion_id=obj.app_config.discussion_id,
>>>>ref_id=obj.index_id())
>>>> return obj
>>>> else:
>>>> pg = cls.upsert(title)
>>>> HC = cls.__mongometa__.history_class
>>>&g
[allura:tickets] Ticket 1699 discussion
- **status**: open --> closed - **assigned_to**: Deshani - **Reviewer**: Dave Brondsema - **Comment**: Done in https://forge-allura.apache.org/p/allura/git/merge-requests/252/ --- ** [tickets:#1699] Fix incoming email for wiki pages with space in the title** **Status:** closed **Milestone:** unreleased **Labels:** bitesize **Created:** Mon Mar 14, 2011 04:17 PM UTC by Rick Copeland **Last Updated:** Mon Aug 24, 2015 03:50 PM UTC **Owner:** Deshani For instance, "Getting The c...@wiki.allura.p.sf.net" is not a valid email address. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Re: #1699 Fix incoming email for wiki pages with space in the title
Sorry for the delays, I will try to get this tomorrow and post feedback on the
merge request tomorrow.
This is a good opportunity to say that delays and time to discuss & coordinate
are inevitable. Its a good reason to keep units of work small enough, and
during "fulltime" work on Allura expect to switch gears to a different tasks on
different branches while waiting for feedback.
Thanks though and hope to post feedback tomorrow!
On 5/4/18 3:47 PM, Deshani Geethika wrote:
> Hi Dave,
>
> I've fixed the issue and added a merge request
> <https://forge-allura.apache.org/p/allura/git/merge-requests/252/>.
>
> Please review it and let me know any improvements.
>
> Regards!
>
> On Fri, May 4, 2018 at 3:13 AM, Dave Brondsema <d...@brondsema.net> wrote:
>
>> I think this method, handling inbound emails to wiki pages, is probably
>> not used
>> very much :) I haven't tried it but it does seem like that would let
>> people
>> create new wiki pages just by emailing to the address.
>>
>> 1) We probably don't need to allow that. Just allow emails to make
>> comments on
>> *existing* wiki pages (which I believe handle_artifact_message does)
>>
>> 2) If you look at `git blame` for handle_message you can see that it is
>> quite
>> old. Some of the very early work on Allura doesn't make perfect sense any
>> more.
>> So in this case it probably would be fine to remove the try/except since
>> as you
>> say upsert() shouldn't raise any exception. And I don't think the
>> underlying
>> get() and upsert() calls within upsert() would raise any either.
>>
>> -Dave
>>
>> On 5/3/18 11:20 AM, Deshani Geethika wrote:
>>> Hi Dave,
>>>
>>> Let's continue the discussion related to the above issue in this thread.
>>>
>>> I have few confusions on the forgewiki.wiki_main.
>> ForgeWikiApp#handle_message
>>> *[1]* method. Inside this method, Page.upsert method *[2]* is called, and
>>> upsert method will update page with 'title' or insert new page with that
>>> name. Does that means, if somebody sends an email to 'Foo_Baz@123' and
>> if
>>> that page is not available, a new page with the title 'Foo_Baz' will be
>>> created? If so, we have some problems.
>>>
>>>1. We can't validate the title
>>>2. 'upsert' method will never throw an exception (But in
>> handle_message
>>>method exception is handled)
>>>
>>>
>>> *[1]*def handle_message(self, topic, message):
>>> log.info('Message from %s (%s)',
>>> topic, self.config.options.mount_point)
>>> log.info('Headers are: %s', message['headers'])
>>> try:
>>> page = WM.Page.upsert(topic)
>>> except:
>>> log.exception('Error getting artifact %s', topic)
>>> self.handle_artifact_message(page, message)
>>>
>>> *[2]* @classmethod
>>> def upsert(cls, title, version=None):
>>> """Update page with `title` or insert new page with that name"""
>>> if version is None:
>>> # Check for existing page object
>>> obj = cls.query.get(
>>> app_config_id=context.app.config._id,
>>> title=title)
>>> if obj is None:
>>> obj = cls(
>>> title=title,
>>> app_config_id=context.app.config._id,
>>> )
>>> Thread.new(discussion_id=obj.app_config.discussion_id,
>>>ref_id=obj.index_id())
>>> return obj
>>> else:
>>> pg = cls.upsert(title)
>>> HC = cls.__mongometa__.history_class
>>> ss = HC.query.find(
>>> {'artifact_id': pg._id, 'version': int(version)}).one()
>>> return ss
>>>
>>> Regards!
>>>
>>> On Thu, May 3, 2018 at 3:21 AM, Dave Brondsema <d...@brondsema.net>
>> wrote:
>>>
>>>> On 5/2/18 11:24 AM, Deshani Geethika wrote:
>>>>> Hi Dave,
>>>>>
>>>>> Thanks for the information. I have few questions to be clarified.
>>>>>
>>>>> I think replacing spaces with underscores would be a good way to do it,
>>>>> since on many wikis they are
>>>>> interchangable. (They aren't for a
Re: #1699 Fix incoming email for wiki pages with space in the title
I think this method, handling inbound emails to wiki pages, is probably not used
very much :) I haven't tried it but it does seem like that would let people
create new wiki pages just by emailing to the address.
1) We probably don't need to allow that. Just allow emails to make comments on
*existing* wiki pages (which I believe handle_artifact_message does)
2) If you look at `git blame` for handle_message you can see that it is quite
old. Some of the very early work on Allura doesn't make perfect sense any more.
So in this case it probably would be fine to remove the try/except since as you
say upsert() shouldn't raise any exception. And I don't think the underlying
get() and upsert() calls within upsert() would raise any either.
-Dave
On 5/3/18 11:20 AM, Deshani Geethika wrote:
> Hi Dave,
>
> Let's continue the discussion related to the above issue in this thread.
>
> I have few confusions on the forgewiki.wiki_main.ForgeWikiApp#handle_message
> *[1]* method. Inside this method, Page.upsert method *[2]* is called, and
> upsert method will update page with 'title' or insert new page with that
> name. Does that means, if somebody sends an email to 'Foo_Baz@123' and if
> that page is not available, a new page with the title 'Foo_Baz' will be
> created? If so, we have some problems.
>
>1. We can't validate the title
>2. 'upsert' method will never throw an exception (But in handle_message
>method exception is handled)
>
>
> *[1]*def handle_message(self, topic, message):
> log.info('Message from %s (%s)',
> topic, self.config.options.mount_point)
> log.info('Headers are: %s', message['headers'])
> try:
> page = WM.Page.upsert(topic)
> except:
> log.exception('Error getting artifact %s', topic)
> self.handle_artifact_message(page, message)
>
> *[2]* @classmethod
> def upsert(cls, title, version=None):
> """Update page with `title` or insert new page with that name"""
> if version is None:
> # Check for existing page object
> obj = cls.query.get(
> app_config_id=context.app.config._id,
> title=title)
> if obj is None:
> obj = cls(
> title=title,
> app_config_id=context.app.config._id,
> )
> Thread.new(discussion_id=obj.app_config.discussion_id,
>ref_id=obj.index_id())
> return obj
> else:
> pg = cls.upsert(title)
> HC = cls.__mongometa__.history_class
> ss = HC.query.find(
> {'artifact_id': pg._id, 'version': int(version)}).one()
> return ss
>
> Regards!
>
> On Thu, May 3, 2018 at 3:21 AM, Dave Brondsema <d...@brondsema.net> wrote:
>
>> On 5/2/18 11:24 AM, Deshani Geethika wrote:
>>> Hi Dave,
>>>
>>> Thanks for the information. I have few questions to be clarified.
>>>
>>> I think replacing spaces with underscores would be a good way to do it,
>>> since on many wikis they are
>>> interchangable. (They aren't for allura, but we could move towards
>> that).
>>>
>>> Here do you mean that spaces and underscores in a title are considered as
>>> same characters?
>>>
>>> For example : "The Title" is considered same as "The_Title".
>>
>> Yes that's what I was thinking.
>>
>>>
>>> In this situation, users should not be allowed to create 2 wikis with
>> above
>>> titles, because we can't handle inbound emails for both scenarios.
>>
>> Good point, I hadn't thought of that. That does make this more
>> complicated.
>> Maybe it could be a followup step to prevent creating a page that
>> conflicts with
>> another one. And then even later on we could make URLs handle spaces and
>> underscores interchangably.
>>
>> Anyone else have ideas about what would be best?
>>
>>>
>>> Also, we have another problem here.
>>>
>>> Then this handle_message method could try finding a page for that
>> message,
>>> and if it
>>> doesn't exist, it can convert any underscores back to spaces and then try
>>> find
>>> the wiki page under that name.
>>>
>>> Here do I need to check for all the possible number of combinations of
>>> underscores and spaces to find out the exact wiki page?
>>
>>
>> I was thinking if an email comes in for "Foo_Bar_Baz" first look for one
>> ti
Re: [GSoC] [COMDEV-254] Allura - Personal Dashboard
On 5/2/18 11:24 AM, Deshani Geethika wrote:
> Hi Dave,
>
> Thanks for the information. I have few questions to be clarified.
>
> I think replacing spaces with underscores would be a good way to do it,
> since on many wikis they are
> interchangable. (They aren't for allura, but we could move towards that).
>
> Here do you mean that spaces and underscores in a title are considered as
> same characters?
>
> For example : "The Title" is considered same as "The_Title".
Yes that's what I was thinking.
>
> In this situation, users should not be allowed to create 2 wikis with above
> titles, because we can't handle inbound emails for both scenarios.
Good point, I hadn't thought of that. That does make this more complicated.
Maybe it could be a followup step to prevent creating a page that conflicts with
another one. And then even later on we could make URLs handle spaces and
underscores interchangably.
Anyone else have ideas about what would be best?
>
> Also, we have another problem here.
>
> Then this handle_message method could try finding a page for that message,
> and if it
> doesn't exist, it can convert any underscores back to spaces and then try
> find
> the wiki page under that name.
>
> Here do I need to check for all the possible number of combinations of
> underscores and spaces to find out the exact wiki page?
I was thinking if an email comes in for "Foo_Bar_Baz" first look for one titled
"Foo_Bar_Baz" and then one titled "Foo Bar Baz". Trying every combination could
get crazy.
>
> Regards!
>
>
>
> On Wed, May 2, 2018 at 7:17 AM, Dave Brondsema <d...@brondsema.net> wrote:
>
>> Cool. That email_address property should be the main one and changing it
>> should
>> reflect in the outgoing emails that are sent to subscribers after
>> commenting or
>> editing a wiki page.
>>
>> Allura also supports *inbound* emails on most artifacts including wiki
>> pages.
>> So someone could reply to the wiki email and it would be received by
>> Allura and
>> added as a comment on the wiki page. The
>> forgewiki.wiki_main.ForgeWikiApp#handle_message method is what is
>> responsible
>> for that. So that code should be updated as well. I think replacing
>> spaces
>> with underscores would be a good way to do it, since on many wikis they are
>> interchangable. (They aren't for allura, but we could move towards
>> that). Then
>> this handle_message method could try finding a page for that message, and
>> if it
>> doesn't exist, it can convert any underscores back to spaces and then try
>> find
>> the wiki page under that name.
>>
>> To test the inbound mails, I'm unfortunately not seeing any tests in the
>> code.
>> You could add some. The ForgeWiki/forgewiki/tests/test_app.py file has a
>> TestBulkExport class and you could copy most of its setup, and then add a
>> test_email test case that calls wiki.handle_message.
>>
>> The other way is to use telnet or other tools like that to send the mail
>> into
>> the "inmail" docker compose container, or `paster smtp_server` service if
>> you
>> aren't using docker. There's an example of doing that in the middle of
>> this
>> page: https://forge-allura.apache.org/p/allura/wiki/Notes/
>>
>> Hope that helps! It sounds a little more complex of a ticket than I
>> initially
>> thought it would be. Let us know if you have any more questions or get
>> stuck on
>> anything.
>>
>> -Dave
>>
>> On 5/1/18 12:45 PM, Deshani Geethika wrote:
>>> Hi all,
>>>
>>> During last few days, I spent time on reading the Allura documentation
>> and
>>> on getting familiarized with Allura codebase.
>>>
>>> Then, I have started to work on the ticket - #1699 Fix incoming email for
>>> wiki pages with space in the title
>>> <https://forge-allura.apache.org/p/allura/tickets/1699/>. According to
>> my
>>> understanding, it is required to replace the spaces in the title with
>> null
>>> string (or with some character). Therefore, the getter method for
>>> email_address which is in Page.class in ForgeWiki/forgewiki/model/wiki
>> .py
>>> should be changed as below.
>>>
>>>
>>> @property
>>> def email_address(self):
>>>if context.app.config.options.get('AllowEmailPosting', True):
>>>domain = self.email_domain
>>> * self.title.replace(‘ ‘,’’) // Added line*
>>>return '%s@%s%s' % (self.titl
Re: [GSoC] [COMDEV-254] Allura - Personal Dashboard
Cool. That email_address property should be the main one and changing it should
reflect in the outgoing emails that are sent to subscribers after commenting or
editing a wiki page.
Allura also supports *inbound* emails on most artifacts including wiki pages.
So someone could reply to the wiki email and it would be received by Allura and
added as a comment on the wiki page. The
forgewiki.wiki_main.ForgeWikiApp#handle_message method is what is responsible
for that. So that code should be updated as well. I think replacing spaces
with underscores would be a good way to do it, since on many wikis they are
interchangable. (They aren't for allura, but we could move towards that). Then
this handle_message method could try finding a page for that message, and if it
doesn't exist, it can convert any underscores back to spaces and then try find
the wiki page under that name.
To test the inbound mails, I'm unfortunately not seeing any tests in the code.
You could add some. The ForgeWiki/forgewiki/tests/test_app.py file has a
TestBulkExport class and you could copy most of its setup, and then add a
test_email test case that calls wiki.handle_message.
The other way is to use telnet or other tools like that to send the mail into
the "inmail" docker compose container, or `paster smtp_server` service if you
aren't using docker. There's an example of doing that in the middle of this
page: https://forge-allura.apache.org/p/allura/wiki/Notes/
Hope that helps! It sounds a little more complex of a ticket than I initially
thought it would be. Let us know if you have any more questions or get stuck on
anything.
-Dave
On 5/1/18 12:45 PM, Deshani Geethika wrote:
> Hi all,
>
> During last few days, I spent time on reading the Allura documentation and
> on getting familiarized with Allura codebase.
>
> Then, I have started to work on the ticket - #1699 Fix incoming email for
> wiki pages with space in the title
> <https://forge-allura.apache.org/p/allura/tickets/1699/>. According to my
> understanding, it is required to replace the spaces in the title with null
> string (or with some character). Therefore, the getter method for
> email_address which is in Page.class in ForgeWiki/forgewiki/model/wiki.py
> should be changed as below.
>
>
> @property
> def email_address(self):
>if context.app.config.options.get('AllowEmailPosting', True):
>domain = self.email_domain
> * self.title.replace(‘ ‘,’’) // Added line*
>return '%s@%s%s' % (self.title.replace('/', '.'), domain,
> config.common_suffix)
>else:
>return tg_config.get('forgemail.return_path')
>
> Could you tell me whether, do I need to modify any method other than the
> above one?
>
>
> Regards!
>
> On Wed, Apr 25, 2018 at 10:30 PM, Deshani Geethika <
> deshanigeeth...@gmail.com> wrote:
>
>> Hi Dave,
>>
>> Thanks for the detailed explanation. I will start working on this and come
>> back to you with my progress
>>
>> Regards!
>>
>> On Wed, Apr 25, 2018 at 9:55 PM, Dave Brondsema <d...@brondsema.net>
>> wrote:
>>
>>> On 4/24/18 11:14 AM, Deshani Geethika wrote:
>>>> Hi Dave,
>>>>
>>>> As per GSoC official time-line, from 23rd April to 14th May period is
>>>> considered as "Community Bonding Period".
>>>>
>>>> During this period I would like to finalize my design and separate my
>>>> project into several tickets. Also, I would like to get more
>>> familiarized
>>>> with Allura code-base and Allura team.
>>>>
>>>> Could you guide me what would be the best way to start off with.
>>>>
>>>> Regards!
>>>>
>>>
>>> Sounds like good goals for the community bonding period.
>>>
>>> I've added you as a developer on our self-hosted Allura project
>>> https://forge-allura.apache.org/p/allura/ which means you can assign
>>> tickets to
>>> yourself, make new ones, update existing ones, etc. I'd recommend having
>>> many
>>> small incremental tickets (perhaps even smaller pieces of work than you
>>> outlined
>>> in the project proposal), so that its easy to manage them and review
>>> them. And
>>> of course you don't need to make them all right away :)
>>>
>>> To familiarize yourself with Allura, you can read more of the
>>> documentation -
>>> assuming you haven't read it all already ;)
>>> https://forge-allura.apache.org/docs/
>>>
>>> And working on Allura code itself is best. Find an existing ticket or
>>> anything
>>> you notice that cou
[allura:tickets] #8201 Mask/hide email addresses in commit messages
- **status**: in-progress --> review - **Comment**: Done on branch db/8201 --- ** [tickets:#8201] Mask/hide email addresses in commit messages** **Status:** review **Milestone:** unreleased **Created:** Tue May 01, 2018 03:28 PM UTC by Dave Brondsema **Last Updated:** Tue May 01, 2018 03:28 PM UTC **Owner:** Dave Brondsema For privacy reasons we should mask email addresses that come through in commit messages (like `Signed-off-by:` lines, etc. Especially since commit messages can't be edited like other allura content after the fact. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8201 Mask/hide email addresses in commit messages
--- ** [tickets:#8201] Mask/hide email addresses in commit messages** **Status:** in-progress **Milestone:** unreleased **Created:** Tue May 01, 2018 03:28 PM UTC by Dave Brondsema **Last Updated:** Tue May 01, 2018 03:28 PM UTC **Owner:** Dave Brondsema For privacy reasons we should mask email addresses that come through in commit messages (like `Signed-off-by:` lines, etc. Especially since commit messages can't be edited like other allura content after the fact. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #6353 Pre-fill "private" using URL param
--- ** [tickets:#6353] Pre-fill "private" using URL param** **Status:** review **Milestone:** unreleased **Labels:** bitesize for-support **Created:** Mon Jun 10, 2013 06:13 PM UTC by Chris Tsai **Last Updated:** Tue Mar 31, 2015 05:31 PM UTC **Owner:** Dave Brondsema Something like https://sourceforge.net/p/forge/site-support/new/?private=true to pre-check the "private" checkbox would be especially nice on pages that ask for tickets for items like security vulnerabilities or anything else that might involve private data. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] Ticket 6353 discussion
- **status**: open --> review - **assigned_to**: Dave Brondsema - **Comment**: Done on branch db/6353 --- ** [tickets:#6353] Pre-fill "private" using URL param** **Status:** review **Milestone:** unreleased **Labels:** bitesize for-support **Created:** Mon Jun 10, 2013 06:13 PM UTC by Chris Tsai **Last Updated:** Tue Mar 31, 2015 05:31 PM UTC **Owner:** Dave Brondsema Something like https://sourceforge.net/p/forge/site-support/new/?private=true to pre-check the "private" checkbox would be especially nice on pages that ask for tickets for items like security vulnerabilities or anything else that might involve private data. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Re: [GSoC] [COMDEV-254] Allura - Personal Dashboard
On 4/24/18 11:14 AM, Deshani Geethika wrote: > Hi Dave, > > As per GSoC official time-line, from 23rd April to 14th May period is > considered as "Community Bonding Period". > > During this period I would like to finalize my design and separate my > project into several tickets. Also, I would like to get more familiarized > with Allura code-base and Allura team. > > Could you guide me what would be the best way to start off with. > > Regards! > Sounds like good goals for the community bonding period. I've added you as a developer on our self-hosted Allura project https://forge-allura.apache.org/p/allura/ which means you can assign tickets to yourself, make new ones, update existing ones, etc. I'd recommend having many small incremental tickets (perhaps even smaller pieces of work than you outlined in the project proposal), so that its easy to manage them and review them. And of course you don't need to make them all right away :) To familiarize yourself with Allura, you can read more of the documentation - assuming you haven't read it all already ;) https://forge-allura.apache.org/docs/ And working on Allura code itself is best. Find an existing ticket or anything you notice that could be made better, and make a fix for it. A really easy one that I could suggest is https://forge-allura.apache.org/p/allura/tickets/1699/ I've also noticed that our test suite has failed the past few times: https://builds.apache.org/blue/organizations/jenkins/Allura/activity It probably is related to the "Make debug pages and post permalinks work correctly when behind a proxy" commit. You could take a look at fixing that if you want. Otherwise I will soon. Lastly, reviewing other people's work is a good way to get familiar with the code and best practices. I will have a fix for https://forge-allura.apache.org/p/allura/tickets/6353/ coming soon, so watch out for that. You won't be able to merge my branch to master, but it can be a good way for you to learn from others. And any constructive feedback would be welcome too, of course. -- Dave Brondsema : d...@brondsema.net http://www.brondsema.net : personal http://www.splike.com : programming <><
Deshani and Google Summer of Code
Deshani Geethika has been accepted as a Google Summer of Code student working on Allura this summer. Welcome, Deshani! Allura might have a small community but we have a big interesting codebase, and follow common open source practices, especially Apache Software Foundation practices. So I hope you learn a lot and the summer goes well. -- Dave Brondsema : d...@brondsema.net http://www.brondsema.net : personal http://www.splike.com : programming <><
[allura:tickets] #8199 2FA recovery codes file - line endings
- **status**: review --> closed - **Reviewer**: Dave Brondsema --- ** [tickets:#8199] 2FA recovery codes file - line endings** **Status:** closed **Milestone:** unreleased **Created:** Thu Apr 19, 2018 06:42 PM UTC by Kenton Taylor **Last Updated:** Thu Apr 19, 2018 07:45 PM UTC **Owner:** Kenton Taylor When downloading 2FA recovery codes, the line endings aren't Windows friendly (CRLF), so all text gets visibly lumped together in one long line when viewing the downloaded file on that Windows. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8198 Ability to remove activity entries
--- ** [tickets:#8198] Ability to remove activity entries** **Status:** in-progress **Milestone:** unreleased **Created:** Fri Mar 30, 2018 08:34 PM UTC by Dave Brondsema **Last Updated:** Fri Mar 30, 2018 08:34 PM UTC **Owner:** Dave Brondsema Sometimes an activity entry is erroneous, has private info, etc, so there should be a way to remove it. Probably limit to neighborhood admins only, for now. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8197 Site admin searches don't do full matches
- **status**: in-progress --> review - **Comment**: Fixed on db/8197 Test the /nf/admin/search_users and /nf/admin/search_projects pages. Now everything you enter should match, no matter the spaces or @s. And wildcards should still work too. `user test` will match `test user X` which isn't ideal, but you can manually add quotes if you want a literal match. A more perfect solution I think would require changing many text fields in solr to string fields, e.g. `email_addresses_t` -> `_s` and `display_name_t` and `project_shortname_t` and `project_name_t` etc. Those really aren't full text fields, just strings, and then escaping spaces with `\ ` might work. But that would be a very big undertaking. --- ** [tickets:#8197] Site admin searches don't do full matches** **Status:** review **Milestone:** unreleased **Created:** Fri Mar 30, 2018 05:08 PM UTC by Dave Brondsema **Last Updated:** Fri Mar 30, 2018 05:08 PM UTC **Owner:** Dave Brondsema Searching for `john doe` doesn't match on "doe" at all. And searching for `f...@bar.com` splits on the @ and matches on either part. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8197 Site admin searches don't do full matches
--- ** [tickets:#8197] Site admin searches don't do full matches** **Status:** in-progress **Milestone:** unreleased **Created:** Fri Mar 30, 2018 05:08 PM UTC by Dave Brondsema **Last Updated:** Fri Mar 30, 2018 05:08 PM UTC **Owner:** Dave Brondsema Searching for `john doe` doesn't match on "doe" at all. And searching for `f...@bar.com` splits on the @ and matches on either part. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8196 Save content before form submission
- **status**: review --> closed --- ** [tickets:#8196] Save content before form submission** **Status:** closed **Milestone:** unreleased **Created:** Wed Mar 14, 2018 06:28 PM UTC by Kenton Taylor **Last Updated:** Wed Mar 28, 2018 07:35 PM UTC **Owner:** Kenton Taylor It would be helpful to save form content before submitting, in case the Antispam spinner/honeypot rejects it, or you get logged out. And obvious restore the content when viewing the form again. Use localStorage? Clear it after a successful submit? And/or after an hour? Also need to deal with spinner field names properly. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8196 Save content before form submission
- **status**: review --> in-progress - **Comment**: * invalidInputName could still use a comment explaining that it is to recognize antispam random names * might as well remove the `autosave: true` from simplemde config if its not doing anything * on a nested reply: * to use a saved value, you have to click the "reply" button again. So its not obvious immediately that your content has been saved (under that particular post), but not sure if we want to automatically expand it * When you do start to restore a reply, you have to click into the editor for the text to show up. Bug report https://github.com/sparksuite/simplemde-markdown-editor/issues/344 has a workaround, also mixed info there about whether an upgrade would fix it. * the saved value doesn't get cleared after a successful submit --- ** [tickets:#8196] Save content before form submission** **Status:** in-progress **Milestone:** unreleased **Created:** Wed Mar 14, 2018 06:28 PM UTC by Kenton Taylor **Last Updated:** Fri Mar 23, 2018 07:12 PM UTC **Owner:** Kenton Taylor It would be helpful to save form content before submitting, in case the Antispam spinner/honeypot rejects it, or you get logged out. And obvious restore the content when viewing the form again. Use localStorage? Clear it after a successful submit? And/or after an hour? Also need to deal with spinner field names properly. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Re: [GSoC] To start contributing to Apache Allura
Comments inline: On 3/26/18 9:04 AM, Deshani Geethika wrote: > Hi All, > > I have few questions to be clarified about Personal Dashboard. > > Currently, when a user is logged in, neighborhoods are shown in the landing > page. We have few options here. > >1. Replace that Neighborhood page with the Personal Dashboard page. Then >we can give a link for Neighborhood page (Like the link for “Account”) >2. Neighborhood page will remain as it is and provide a link for >“Dashboard”. (Like the link for “Account”) >3. Merge these two pages. That means include neighborhoods in Personal >Dashboard > Yeah the current landing page with neighborhoods is not super great right now anyway. Tickets 7308 and 2601 are related to that and maybe could be a stretch goal if your proposal were accepted and there was extra time. Anyway, for this. I think separate pages would good. One idea would be to show the personal dashboard if logged in, and the neighborhood page if not logged in. Maybe have separate URLs like /dashboard and /index so you can still access both when logged in and "/" would redirect. > > According to the project description > <https://issues.apache.org/jira/browse/COMDEV-254?filter=12343065>, when > implementing the Personal Dashboard we can use a pluggable structure as in > User Profile. Therefore, I have included the personal_dashboard directory > in Allura/allura/ext/personal_dashboard path. Furthermore, the whole folder > and file structure can be depicted as below. > > > > Is it alright to reside the personal_dashboard directory in above path or > else do we have any other better option? Also, please let me know whether > this file and folder structure is alright. Yes, modeling things after the user profile pluggable structure is good. This path is a good one. > > Moreover, I have included the whole design in my GSoC proposal and I have > uploaded my drafted GSoC proposal to Apache Software Foundations via > official GSoC site <https://summerofcode.withgoogle.com/>. Let me know any > suggestions for the design and also for the proposal. Please find the link > for the proposal below. > > Proposal : > > https://docs.google.com/document/d/1clWKSJ8-ektpVaEgiJyoM34ievwkyCnD4uORMCT0eM8/edit?usp=sharing > I've made just one minor suggestion on the proposal so far. Overall it is pretty good. The most important things are: showing a detailed plan, breaking it down into small steps in the timeline, and being able to fully commit to all the time during the summer. Those are covered pretty well. If you do have any exams or vacation time, please include that in your commitment section. I'll add more comments if I think of more constructive feedback. > Regards! > > On Fri, Mar 23, 2018 at 10:07 PM, Deshani Geethika < > deshanigeeth...@gmail.com> wrote: > >> Hi Dave, >> >> I have drafted the GSoC proposal and would like to get feedback from you. >> >> Please review it from here: >> GSoC Proposal >> <https://docs.google.com/document/d/1clWKSJ8-ektpVaEgiJyoM34ievwkyCnD4uORMCT0eM8/edit?usp=drive_web> >> >> Regards! >> >> On Thu, Mar 22, 2018 at 9:14 PM, Dave Brondsema <d...@brondsema.net> >> wrote: >> >>> I've commented on the merge request. >>> >>> The personal dashboard project would be a great. >>> https://community.apache.org/gsoc.html has some information about what >>> makes a >>> good application. I would recommend you write up a draft of your >>> proposal ideas >>> and share it either here on the Allura dev mailing list for public >>> feedback, or >>> to me privately if you prefer. Getting feedback on your proposal is >>> allowed and >>> helpful. >>> >>> >>> On 3/21/18 2:02 PM, Deshani Geethika wrote: >>>> Hi Dave, >>>> >>>> Thank you for reviewing my merge request :) I’ve refracted the code and >>>> added the test coverage as described. Please review it and let me know >>> any >>>> suggestions. Merge request can be found in [1] >>>> >>>> Meanwhile, I would like to start working on a GSoC project as I’ve got >>> some >>>> decent exposure to Allura code-base now. When going through the projects >>>> list, I’ve found out the project *[COMDEV-254] Allura - personal >>> dashboard* >>>> [2] fits my interests. >>>> >>>> But, if there is any high prioritized project other than this, I would >>>> equally interested in accepting it as well. I’m looking forward to know >>>> further information i
[allura:tickets] #8149 Bulk Delete for tickets
- **status**: open --> closed - **assigned_to**: Deshani - **Reviewer**: Dave Brondsema - **Comment**: Done in https://forge-allura.apache.org/p/allura/git/merge-requests/248/ --- ** [tickets:#8149] Bulk Delete for tickets** **Status:** closed **Milestone:** unreleased **Created:** Tue Mar 21, 2017 03:57 PM UTC by Dave Brondsema **Last Updated:** Fri Mar 31, 2017 03:18 PM UTC **Owner:** Deshani Request originally from https://sourceforge.net/p/forge/feature-requests/415/ Current workaround is bulk move to a temp ticket tracker, than delete that tracker tool altogether. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Re: [GSoC] To start contributing to Apache Allura
I've commented on the merge request. The personal dashboard project would be a great. https://community.apache.org/gsoc.html has some information about what makes a good application. I would recommend you write up a draft of your proposal ideas and share it either here on the Allura dev mailing list for public feedback, or to me privately if you prefer. Getting feedback on your proposal is allowed and helpful. On 3/21/18 2:02 PM, Deshani Geethika wrote: > Hi Dave, > > Thank you for reviewing my merge request :) I’ve refracted the code and > added the test coverage as described. Please review it and let me know any > suggestions. Merge request can be found in [1] > > Meanwhile, I would like to start working on a GSoC project as I’ve got some > decent exposure to Allura code-base now. When going through the projects > list, I’ve found out the project *[COMDEV-254] Allura - personal dashboard* > [2] fits my interests. > > But, if there is any high prioritized project other than this, I would > equally interested in accepting it as well. I’m looking forward to know > further information in order to apply for Allura GSoC projects. > > [1] https://forge-allura.apache.org/p/allura/git/merge-requests/248/ > [2] https://issues.apache.org/jira/browse/COMDEV-254?filter=12343065 > > Regards! > > On Tue, Mar 20, 2018 at 10:14 PM, Dave Brondsema <d...@brondsema.net> wrote: > >> No problem! I'll take a look and post feedback on the merge request. >> >> On 3/20/18 1:36 AM, Deshani Geethika wrote: >>> Hi Dave, >>> >>> Sorry for messing up. I've created a merge request - >>> https://forge-allura.apache.org/p/allura/git/merge-requests/248/ >>> >>> Regards! >>> >>> On Mon, Mar 19, 2018 at 9:01 PM, Dave Brondsema <d...@brondsema.net> >> wrote: >>> >>>> Hi Deshani, >>>> >>>> Thanks for the contribution! Would you mind going to >>>> https://forge-allura.apache.org/p/allura/git/ and doing a fork and >> merge >>>> request >>>> there? Allura does its own hosting and we prefer to use that. The >> GitHub >>>> repo >>>> is just a mirror. >>>> >>>> Thanks, >>>> >>>> On 3/18/18 5:24 AM, Deshani Geethika wrote: >>>>> Hi all, >>>>> >>>>> I've added the functionality for bulk delete tickets and created a pull >>>>> request - https://github.com/apache/allura/pull/2 >>>>> >>>>> Please review it and provide me any suggestions. >>>>> >>>>> Regards! >>>>> >>>>> On Sun, Mar 18, 2018 at 10:52 AM, Deshani Geethika < >>>>> deshanigeeth...@gmail.com> wrote: >>>>> >>>>>> Hi Dave, >>>>>> >>>>>> Thank you for the information. I'll try it again and let you know >>>>>> >>>>>> Regards! >>>>>> Deshani >>>>>> >>>>>> On Fri, Mar 16, 2018 at 2:52 AM, Dave Brondsema <d...@brondsema.net> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Your changes look ok just reading them. What happens when you try >> it? >>>>>>> Do you >>>>>>> get any error? >>>>>>> >>>>>>> One thought is that bulk edit happens as a background task (because >>>>>>> updating >>>>>>> hundreds of tickets could take some time). Specifically @task >>>> bulk_edit >>>>>>> is what >>>>>>> calls Globals.update_tickets So make sure you have taskd running. >> And >>>>>>> if it is >>>>>>> running, check to see if bulk_edit task runs and if it has any >> errors. >>>>>>> >>>>>>> Hope that helps, >>>>>>> >>>>>>> On 3/15/18 9:22 AM, Deshani Geethika wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> During last few days, I’ve been playing with Allura code-base and >>>>>>> started >>>>>>>> to work on the issue #8149 Bulk Delete for tickets ( >>>>>>>> https://forge-allura.apache.org/p/allura/tickets/8149/) >>>>>>>> >>>>>>>> I have modified the file >>>>>>>> ‘ForgeTracker/forgetracker/templates/tracker_widgets/ma
[allura:tickets] #8196 Save content before form submission
- **status**: review --> open - **Reviewer**: Dave Brondsema - **Comment**: Nice overall structure, and commenting/documentation. This is going to be great. * `memorable_forget`'s `_inner` should only catch HTTP exceptions I think. Safer and more clear about what its doing. * Does the SimpleMDE config `autosave:true` do anything? * there are some `sisyphus` references I don't think we need * blog post successful submit doesn't set memorable_forget cookie. Same for a nested reply. ### `memorable.js` * shouldn't use a `SF` namespace * `Memorable.initialize` looks to do similar work as `Memorable.add`, could it call `add`? * `name.length != 28` - what is that about? * the loop`i = 3; i < list.length`... also could do .slice() and .join() instead of a loop * commenting on a blog post generates storage key `/p/test/blog/_discuss/thread/ce912605/post__None` is that None ok? same for creating a new discussion topic. * memorable_forget cookie only triggers clearing if memorable.js runs on the page? Not too big a deal since the cookie will stick around until you visit a page with it, but maybe better to have clearing behavior run separate from the saving behavior ### User Experience * if I intentionally navigate away, it may be surprising to see saved text from long ago when I come back. (even more so if I click "cancel" on a form) * maybe could refine our logic to only save for a duration of time? not sure. At a minimum we could have 'cancel' links clear the storage * probably a separate ticket, but if i get logged out and then try to do a POST I get sent to /auth/ without any return_to. Probably should have a return_to of the referrer (e.g. wiki edit, ticket edit page) * should an intentional logout clear all the local storage? I think so, for privacy. --- ** [tickets:#8196] Save content before form submission** **Status:** open **Milestone:** unreleased **Created:** Wed Mar 14, 2018 06:28 PM UTC by Kenton Taylor **Last Updated:** Wed Mar 14, 2018 06:45 PM UTC **Owner:** Kenton Taylor It would be helpful to save form content before submitting, in case the Antispam spinner/honeypot rejects it, or you get logged out. And obvious restore the content when viewing the form again. Use localStorage? Clear it after a successful submit? And/or after an hour? Also need to deal with spinner field names properly. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Re: [GSoC] To start contributing to Apache Allura
Hi Deshani,
Thanks for the contribution! Would you mind going to
https://forge-allura.apache.org/p/allura/git/ and doing a fork and merge request
there? Allura does its own hosting and we prefer to use that. The GitHub repo
is just a mirror.
Thanks,
On 3/18/18 5:24 AM, Deshani Geethika wrote:
> Hi all,
>
> I've added the functionality for bulk delete tickets and created a pull
> request - https://github.com/apache/allura/pull/2
>
> Please review it and provide me any suggestions.
>
> Regards!
>
> On Sun, Mar 18, 2018 at 10:52 AM, Deshani Geethika <
> deshanigeeth...@gmail.com> wrote:
>
>> Hi Dave,
>>
>> Thank you for the information. I'll try it again and let you know
>>
>> Regards!
>> Deshani
>>
>> On Fri, Mar 16, 2018 at 2:52 AM, Dave Brondsema <d...@brondsema.net>
>> wrote:
>>
>>> Hi,
>>>
>>> Your changes look ok just reading them. What happens when you try it?
>>> Do you
>>> get any error?
>>>
>>> One thought is that bulk edit happens as a background task (because
>>> updating
>>> hundreds of tickets could take some time). Specifically @task bulk_edit
>>> is what
>>> calls Globals.update_tickets So make sure you have taskd running. And
>>> if it is
>>> running, check to see if bulk_edit task runs and if it has any errors.
>>>
>>> Hope that helps,
>>>
>>> On 3/15/18 9:22 AM, Deshani Geethika wrote:
>>>> Hi all,
>>>>
>>>> During last few days, I’ve been playing with Allura code-base and
>>> started
>>>> to work on the issue #8149 Bulk Delete for tickets (
>>>> https://forge-allura.apache.org/p/allura/tickets/8149/)
>>>>
>>>> I have modified the file
>>>> ‘ForgeTracker/forgetracker/templates/tracker_widgets/mass_
>>> edit_form.html’
>>>> and added the following set of lines, which is similar to ‘Private’
>>> field
>>>> with just boolean values.
>>>>
>>>> ………...
>>>>
>>>>
>>>>
>>>> Delete:
>>>>
>>>>
>>>>
>>>>Don't change
>>>>
>>>>True
>>>>
>>>>False
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ………...
>>>>
>>>> Then, in ‘model/ticket.py’, class ‘Globals’, method ‘update_tickets’, I
>>>> have added following set of lines.
>>>>
>>>> ……...
>>>>
>>>> private = post_data.get('private')
>>>>
>>>> if private:
>>>>
>>>>values['private'] = asbool(private)
>>>>
>>>> deleted = post_data.get('deleted')
>>>>
>>>> if deleted:
>>>>
>>>> values['deleted'] = asbool(deleted)
>>>>
>>>> ……...
>>>>
>>>> Here, the value of ‘deleted’, which is submitted from
>>> ‘mass_edit_form.html’
>>>> is read and saved to ‘values’ dictionary.
>>>>
>>>> Then in the same method, as far as I understood, I have to add the
>>>> functionality for mass delete. Also, I’ve found out the ‘delete’ method
>>>> which is implemented to delete a single ticket in
>>>> ‘ForgeTracker/forgetracker/tracker_main.py’
>>>> class.
>>>>
>>>> Therefore, I have imported the ‘delete’ method from above class, and use
>>>> that method directly to delete tickets one by one (inside the tickets
>>> loop)
>>>> as below. I’ve assumed that, if a user needs to delete tickets, then
>>> other
>>>> fields (Private, Owner, Discussion Disabled etc.) are not required to be
>>>> modified. So that, if a ticket is deleted, the loop breaks without
>>> further
>>>> modifying the ticket.
>>>>
>>>> …..
>>>>
>>>> def update_tickets(self, **post_data):
>>>>
>>>>from forgetracker.tracker_main import get_change_text, get_label,
>>>> delete
>>>>
>>>> ……….
>>>>
>>>> for ticket in tickets:
>>>>
>>>> message = ''
>>>>
>>>> if labels:
>>>>
>>>> values['labels'] = self.append_new_labels(
>>>>
>>>> ticket.labels, labels.split(','))
>>>>
>>>>
[allura:tickets] #8186 Make antispam form post expiration configurable
- **status**: review --> closed - **Reviewer**: Dave Brondsema --- ** [tickets:#8186] Make antispam form post expiration configurable** **Status:** closed **Milestone:** unreleased **Created:** Wed Feb 21, 2018 05:31 PM UTC by Kenton Taylor **Last Updated:** Wed Feb 21, 2018 05:33 PM UTC **Owner:** Kenton Taylor --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Re: [GSoC] To start contributing to Apache Allura
Hi,
Your changes look ok just reading them. What happens when you try it? Do you
get any error?
One thought is that bulk edit happens as a background task (because updating
hundreds of tickets could take some time). Specifically @task bulk_edit is what
calls Globals.update_tickets So make sure you have taskd running. And if it is
running, check to see if bulk_edit task runs and if it has any errors.
Hope that helps,
On 3/15/18 9:22 AM, Deshani Geethika wrote:
> Hi all,
>
> During last few days, I’ve been playing with Allura code-base and started
> to work on the issue #8149 Bulk Delete for tickets (
> https://forge-allura.apache.org/p/allura/tickets/8149/)
>
> I have modified the file
> ‘ForgeTracker/forgetracker/templates/tracker_widgets/mass_edit_form.html’
> and added the following set of lines, which is similar to ‘Private’ field
> with just boolean values.
>
> ………...
>
>
>
> Delete:
>
>
>
>Don't change
>
>True
>
>False
>
>
>
>
>
> ………...
>
> Then, in ‘model/ticket.py’, class ‘Globals’, method ‘update_tickets’, I
> have added following set of lines.
>
> ……...
>
> private = post_data.get('private')
>
> if private:
>
>values['private'] = asbool(private)
>
> deleted = post_data.get('deleted')
>
> if deleted:
>
> values['deleted'] = asbool(deleted)
>
> ……...
>
> Here, the value of ‘deleted’, which is submitted from ‘mass_edit_form.html’
> is read and saved to ‘values’ dictionary.
>
> Then in the same method, as far as I understood, I have to add the
> functionality for mass delete. Also, I’ve found out the ‘delete’ method
> which is implemented to delete a single ticket in
> ‘ForgeTracker/forgetracker/tracker_main.py’
> class.
>
> Therefore, I have imported the ‘delete’ method from above class, and use
> that method directly to delete tickets one by one (inside the tickets loop)
> as below. I’ve assumed that, if a user needs to delete tickets, then other
> fields (Private, Owner, Discussion Disabled etc.) are not required to be
> modified. So that, if a ticket is deleted, the loop breaks without further
> modifying the ticket.
>
> …..
>
> def update_tickets(self, **post_data):
>
>from forgetracker.tracker_main import get_change_text, get_label,
> delete
>
> ……….
>
> for ticket in tickets:
>
> message = ''
>
> if labels:
>
> values['labels'] = self.append_new_labels(
>
> ticket.labels, labels.split(','))
>
>for k, v in sorted(values.iteritems()):
>
>if k == 'deleted':
>
> if v:
>
> ticket.delete()
>
> break
>
>elif k == 'assigned_to_id':
>
>new_user = User.query.get(_id=v)
>
>old_user = User.query.get(_id=getattr(ticket, k))
>
>if new_user:
>
>message += get_change_text(
>
>get_label(k),
>
>new_user.display_name,
>
>old_user.display_name)
>
>
>
>elif k == 'private' or k == 'discussion_disabled':
>
> def _text(val):
>
>if val:
>
>return 'Yes'
>
>else:
>
>return 'No'
>
>message += get_change_text(
>
>get_label(k),
>
>_text(v),
>
>_text(getattr(ticket, k)))
>
>else:
>
> message += get_change_text(
>
>get_label(k),
>
> v,getattr(ticket, k))
>
> setattr(ticket, k, v)
>
> ……….
>
> But, the mass delete functionality is not working and I’m not sure whether
> I’m on the right path. Could you help me to solve this issue.
>
> Regards!
>
> Deshani
>
> On Fri, Mar 9, 2018 at 10:46 PM, Deshani Geethika <deshanigeeth...@gmail.com
>> wrote:
>
>> Hi Dave,
>>
>> Thank you for your guidance. I'll get back if I get anything to be
>> clarified
>>
>> Regards!
>> -Deshani
>>
>> On Fri, Mar 9, 2018 at 9:55 PM, Dave Brondsema <d...@brondsema.net> wrote:
>>
>>> Hi Deshani,
>>>
>>> Welcome! Sounds like you're off to a good start. I would suggest getting
>>> familiar with the codebase of Allura would be a good next step.
>>> https://forge-allura.apache.org/docs/development/c
[allura:tickets] #8190 HTTP response splitting vulnerability on return_to param CVE-2018-1319
- **private**: Yes --> No --- ** [tickets:#8190] HTTP response splitting vulnerability on return_to param CVE-2018-1319** **Status:** closed **Milestone:** v1.8.1 **Labels:** security **Created:** Tue Feb 27, 2018 04:12 PM UTC by Dave Brondsema **Last Updated:** Wed Mar 14, 2018 07:42 PM UTC **Owner:** Dave Brondsema >From a security reporter: -- Summary: To trigger the vulnerability, an attacker would send a malicious "/auth" URL to the victim. The victim would access said URL, and login successfully. The server would then respond with any HTTP headers the attacker supplied in the malicious URL. Please note that the URL points to the real Allura server, and contains control characters (%0d%0a) in the return_to URL parameter. PoC URLs: http:///auth/?return_to=/%0d%0aSet-Cookie:%20%3Bmy-cookie-field%3Dfoobar%3B http:///auth/?return_to=/%0d%0aContent-Length:%20777 The first URL will set the attacker-supplied cookie (my-cookie-field=foobar) to the victim's session. The second URL will make the server respond with a content length of 777, which will force the victim's browser to abort the rendering of the page, since 777 will not match with the real content length. -- `return_to` is used in many places, any of which could sanitize it. Seems like `authenticate_request` and `LoginRedirectMiddleware` and `do_login` and `do_multifactor` have the `redirect()` calls that are the critical spots though. `_verify_return_to` usage could be expanded. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[SECURITY] CVE-2018-1319 Apache Allura HTTP response splitting
CVE-2018-1319 Apache Allura HTTP response splitting Severity: Important Versions Affected: All Description: Attackers may craft URLs that cause HTTP response splitting. If a victim goes to a maliciously crafted URL, unwanted results may occur including XSS or service denial for the victim's browsing session. Mitigation: Users of Allura should upgrade to Allura 1.8.1 immediately. Credit: This issue was discovered by Everardo Padilla Saca
[allura:tickets] #8195 More test coverage for rate limiting
- **status**: review --> closed - **Reviewer**: Dave Brondsema --- ** [tickets:#8195] More test coverage for rate limiting** **Status:** closed **Milestone:** unreleased **Created:** Mon Mar 12, 2018 04:56 PM UTC by Kenton Taylor **Last Updated:** Mon Mar 12, 2018 04:58 PM UTC **Owner:** Kenton Taylor --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8194 Persist the list of commits on Merge requests
- **status**: in-progress --> review - **Comment**: db/8194 * make sure to restart taskd, so it gets the code changes * test as a project admin, which as a one-click merge button, and thus more code runs to check mergability * the cached list of commits won't update if there are new commits upstream (origin) e.g. if a single commit was cherry-picked, or if there was some branch with shared commits that got merged. I think that is ok though, since it keeps thing simpler, and is not really a big problem if it does happen. Moreover, if we did update the list of commits, it would go to 0 after the merge request got merged, which is what we're trying to avoid :) --- ** [tickets:#8194] Persist the list of commits on Merge requests** **Status:** review **Milestone:** unreleased **Created:** Thu Mar 08, 2018 07:24 PM UTC by Dave Brondsema **Last Updated:** Thu Mar 08, 2018 07:24 PM UTC **Owner:** Dave Brondsema This will provide a performance improvement over running `merge_request_commits` every time the page is viewed. It will also allow a merge request to continue to show its list of commits after it has been merged. (Currently they will show no commits, since the downstream fork has nothing new relative to the upstream primary) --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Re: [VOTE] Release of Apache Allura 1.8.1
+1 On 3/8/18 5:04 PM, Kenton Taylor wrote: > +1 > > > --- > Kenton Taylor > Principal Engineer - sourceforge.net > Phone: 616-425-9149 > > On Thu, Mar 8, 2018 at 5:03 PM, Kenton Taylor <ktay...@slashdotmedia.com> > wrote: > >> Hello, >> >> This is a call for a vote on Apache Allura 1.8.1. >> >> Source tarball, signature and checksums are available at: >> https://dist.apache.org/repos/dist/dev/allura/ >> >> Checksums: >> SHA1: bec9a3c50a492fc29c683a6435d1776cc3010987 allura-1.8.1.tar.gz >> SHA512: d08fa80fb23da753241fe591c607eb7dabc495cafb8b8ed57eb5a7e5a207 >> 9f8d41e14a53ee73620334fd051e4402b4686c049639d50aa9eec0f8c97fd7b09f52 >> allura-1.8.1.tar.gz >> >> The KEYS file can be found at: >> http://www.apache.org/dist/allura/KEYS >> >> The release has been signed with key B05BB2D2AEAC6993425494FC94BD8E >> F63B645235: >> http://pgp.mit.edu:11371/pks/lookup?op=vindex= >> 0xB05BB2D2AEAC6993425494FC94BD8EF63B645235 >> >> Source corresponding to this release can be found at: >> Commit: 40ee1b5c91451d027a14cc60e017048d1bd6b1e1 >> Tag:rel/1.8.1 (pending successful vote) >> Browse: https://forge-allura.apache.org/p/allura/git/ci/ >> 40ee1b5c91451d027a14cc60e017048d1bd6b1e1/log/ >> >> Changes for this version are listed at: >> https://forge-allura.apache.org/p/allura/git/ci/ >> 40ee1b5c91451d027a14cc60e017048d1bd6b1e1/tree/CHANGES >> >> The RAT license report is available at: >> https://forge-allura.apache.org/p/allura/pastebin/ >> 5aa1af964227c74cb6f76c78 >> >> Vote will be open for at least 72 hours. Votes from Allura PMC members >> are binding, >> but we welcome all community members to vote as well. >> >> [ ] +1 approve >> [ ] +0 no opinion >> [ ] -1 disapprove (and reason why) >> >> Thanks & Regards >> >> --- >> Kenton Taylor >> Principal Engineer - sourceforge.net >> Phone: 616-425-9149 <(616)%20425-9149> >> > -- Dave Brondsema : d...@brondsema.net http://www.brondsema.net : personal http://www.splike.com : programming <><
[allura:tickets] #8193 Allow rate-limiting of comments
- **status**: review --> closed - **Reviewer**: Dave Brondsema --- ** [tickets:#8193] Allow rate-limiting of comments** **Status:** closed **Milestone:** unreleased **Created:** Wed Mar 07, 2018 03:45 PM UTC by Kenton Taylor **Last Updated:** Thu Mar 08, 2018 07:00 PM UTC **Owner:** Kenton Taylor Creating of tickets, wikis, projects, etc can all be optionally rate-limited. We should allow the same ability for posting comments. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8194 Persist the list of commits on Merge requests
--- ** [tickets:#8194] Persist the list of commits on Merge requests** **Status:** in-progress **Milestone:** unreleased **Created:** Thu Mar 08, 2018 07:24 PM UTC by Dave Brondsema **Last Updated:** Thu Mar 08, 2018 07:24 PM UTC **Owner:** Dave Brondsema This will provide a performance improvement over running `merge_request_commits` every time the page is viewed. It will also allow a merge request to continue to show its list of commits after it has been merged. (Currently they will show no commits, since the downstream fork has nothing new relative to the upstream primary) --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8193 Allow rate-limiting of comments
- **Comment**: * posting a new topic/thread in a forum bypasses the check * on tickets/forums/blog, the `..` redirect goes a url that isn't very end-user-friendly, and it 404s if doing a reply. Maybe redirect to request.referer? * `development.ini` config probably should have a comment to explain that "allura" covers all comments/posts --- ** [tickets:#8193] Allow rate-limiting of comments** **Status:** review **Milestone:** unreleased **Created:** Wed Mar 07, 2018 03:45 PM UTC by Kenton Taylor **Last Updated:** Wed Mar 07, 2018 05:06 PM UTC **Owner:** Kenton Taylor Creating of tickets, wikis, projects, etc can all be optionally rate-limited. We should allow the same ability for posting comments. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8193 Allow rate-limiting of comments
- **status**: review --> in-progress --- ** [tickets:#8193] Allow rate-limiting of comments** **Status:** in-progress **Milestone:** unreleased **Created:** Wed Mar 07, 2018 03:45 PM UTC by Kenton Taylor **Last Updated:** Wed Mar 07, 2018 11:11 PM UTC **Owner:** Kenton Taylor Creating of tickets, wikis, projects, etc can all be optionally rate-limited. We should allow the same ability for posting comments. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8192 StopForumSpam filter and moderation+spam update
- **summary**: StopForumSpam filter --> StopForumSpam filter and moderation+spam update - Description has changed: Diff: --- old +++ new @@ -1 +1,3 @@ There's an existing SpamFilter interface we can use to implement filtering with StopForumSpam files. And it'd be good to expand the spam filters to support using multiple filters not just one. + +Also posts that are already destined for moderation, and are also spam still just end up in the moderation queue. Changes here will put them directly into the 'spam' status and not show up in moderation. - **status**: in-progress --> review - **Comment**: db/8192 branch * new entry point for stopforumspam needs to be registered, so run: `docker-compose run taskd python setup.py develop` * download a file like listed_ip_180_all.txt from https://www.stopforumspam.com/downloads * add some settings to development.ini to test, e.g.: ``` spam.method = stopforumspam spam.stopforumspam.ip_addr_file = /allura/listed_ip_180_all.txt ``` * ip addresses within docker can be a bit weird. To test, I printed the `ip` result from `StopForumSpamSpamFilter.check` and then added that ip address to the .txt file --- ** [tickets:#8192] StopForumSpam filter and moderation+spam update** **Status:** review **Milestone:** unreleased **Created:** Tue Mar 06, 2018 10:29 PM UTC by Dave Brondsema **Last Updated:** Tue Mar 06, 2018 10:29 PM UTC **Owner:** Dave Brondsema There's an existing SpamFilter interface we can use to implement filtering with StopForumSpam files. And it'd be good to expand the spam filters to support using multiple filters not just one. Also posts that are already destined for moderation, and are also spam still just end up in the moderation queue. Changes here will put them directly into the 'spam' status and not show up in moderation. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8192 StopForumSpam filter
--- ** [tickets:#8192] StopForumSpam filter** **Status:** in-progress **Milestone:** unreleased **Created:** Tue Mar 06, 2018 10:29 PM UTC by Dave Brondsema **Last Updated:** Tue Mar 06, 2018 10:29 PM UTC **Owner:** Dave Brondsema There's an existing SpamFilter interface we can use to implement filtering with StopForumSpam files. And it'd be good to expand the spam filters to support using multiple filters not just one. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8191 Remove html-only mailing options
- **status**: open --> review - **assigned_to**: Dave Brondsema - **Comment**: Fix on branch db/8191 To review: * `docker-compose restart taskd` (since it doesn't auto restart like the webapp does) * `docker-compose logs --follow outmail` to see email output * check that email goes out as either text only, or multipart text + html, depending on users' setting * if someone was on "HTML"-only before, they should now get multipart email and the UI will show as "HTML" for them. --- ** [tickets:#8191] Remove html-only mailing options** **Status:** review **Milestone:** unreleased **Created:** Tue Feb 27, 2018 06:03 PM UTC by Dave Brondsema **Last Updated:** Tue Feb 27, 2018 06:03 PM UTC **Owner:** Dave Brondsema On /auth/subscriptions/ their are choices for HTML, Plain Text, or Combined emails. Sending html-only mails can trigger spam warnings like this one from spamassassin: 2.3 MIME_HTML_ONLY BODY: Message only has text/html MIME parts There's no reason we need to offer HTML-only. All HTML mail clients can handle multipart (combined) mails. So I think we should consider all HTML-only preferences as "Combined". And on the preferences page, remove "HTML" and then rename "Combined" to "HTML" (or rich text / formatted / something better?) --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[allura:tickets] #8189 Fix slow forum listings
- **labels**: --> performance - **status**: review --> closed --- ** [tickets:#8189] Fix slow forum listings** **Status:** closed **Milestone:** unreleased **Labels:** performance **Created:** Mon Feb 26, 2018 02:27 PM UTC by Kenton Taylor **Last Updated:** Tue Feb 27, 2018 10:28 PM UTC **Owner:** Kenton Taylor The forum listings page can be very slow to load when there are a large number of topics. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
