{23} Trac comments (3729 matches)

Results (1301 - 1400 of 3729)

Ticket Posixtime Author Newvalue
#364 1291637291000000 rgrp Have now switched to solr search (and maybe working in postgres by now). Note correct link is http://ckan.net/package?q=statistics
#1761 1328703769000000 ross Have overridden the history function in the DGU package_gov3.py controller to make sure the viewer is in at least one group.
#2513 1340187230000000 ross Have pushed back to 1.9 but if may be the the converter service will replace it in the meantime.
#833 1295263447000000 rgrp Have repo https://bitbucket.org/okfn/ckanext-admin
#447 1294410738000000 memespring Have you got a link or screengrab?
#1451 1321876014000000 johnglover Haven't looked at this yet, moving to new sprint
#463 1294916148000000 dread Haven't seen this for ages.
#435 1298284084000000 thejimmyg Haven't seen this myself and it is 6 months old now.
#864 1291741028000000 memespring Havent implemented all text changes because worried about impact on other themes.
#1737 1336328947000000 rgrp Having now thought about this I'm re-opening this ticket for the following reasons: * No real documentation (other than that in this ticket yet available) * It would also be nice to know how this maps to SOLR API (can i use all of the facet options solr provides or not ...?) * And I would again emphasize my preference for having *direct* access to something that looks *exactly* like SOLR API as I can then use client and docs from SOLR to work with it. * No clear resolution of separation between Action and REST API (and search API). Really seems to me there should be convergence between latter 2 (as suggested in the ticket) -- this would also resolve the problem that having GET /api/dataset return all datasets is *not* a great idea * The Action API requires a POST request. Since the primary purpose of the search API would be usage from JS it would be nice if GET and JSONP were supported. (Though given our CORS support we could argue this was optional). Not saying *all* of this needs fixing but some clear approach here would be useful
#972 1310134129000000 thejimmyg Having thought about this more David Raznick and I have decided to stick with separate extras for the timebeing. Mainly because of internationalisation issues.
#2445 1338472966000000 ross He didn't say but I assumed yes given current impl uses dodgy JS->API.
#881 1294410574000000 thejimmyg Hello fccoelho, Could you please post the output you get from running pip? Thanks, James
#1040 1328806824000000 dread Here are all the CKAN instances potentially involved in this issue: == ckan.net / DGU == These suffered this problem briefly and were fixed 15/3/11 == opengov_es http://opengov.es/ 1.2 == This does not have a theme extension. Is not serving files from root. == nosdonnees_fr http://www.nosdonnees.fr/ 1.3.1a == This does have a theme extension but does not seem to have a trailing blank public path since it is not serving files from root.
#698 1292596589000000 Stiivi Here is the fork for (json) data proxy: https://bitbucket.org/Stiivi/dataproxy I've refactored it and moved transformations into separate modules. For each resource type there should be a module in transform/<type>_transform.py Each module should implement ``transform(flow, url, query)`` and should return a dictionary as a result. Existing modules: * transform/csv_transform - CSV files * transform/xls_transform - Excel XLS files if there is no resource_type module, HTTP 200 Error Resource type not supported is returned. You can override URL file extension or specify type if extension is missing through type= URL option. For example if you have any URL that contains CSV data however the url is just foo.com/data then you can pass: url=http://foo.com/data&type=csv Note: Source refactored/updated in example/dataproxy, being tested by running locally localhost:8000.
#1004 1323187352000000 dread Here is the unclipped version: {{{ <p> <span i18n:msg="" class="ckan-logged-in" style="display: none;"> <a href="${h.url_for(controller='group',action='new', id=None)}">Create a new group</a> </span> <span i18n:msg="" class="ckan-logged-out"> To create a new group, please first <a href="${h.url_for(controller='user',action='login', id=None)}">log-in</a>. </span> </p> }}} {{{ <li py:attrs="{'class':'current-tab'} if c.action=='new' else {}" class="ckan-logged-in" style="display: none;"> ${h.subnav_link(c, h.icon('group_add') + _('Add a Group'), controller='group', action='new')} </li> <li py:attrs="{'class':'current-tab'} if c.action=='new' else {}" class="ckan-logged-out"> ${h.subnav_link(c, h.icon('group_add') + _('Log-in to add a Group'), controller='group', action='new')} </li> }}}
#318 1349778662000000 dread Here's a real example - one of many from MOD {{{http://www.dasa.mod.uk/applications/newWeb/www/index.php?page=48&thiscontent=180&date=2011-05-26&pubType=1&PublishTime=09:30:00&from=home&tabOption=1}}} Browsers accept colons and slashes happily, which is the main usage of our links. The URL looks better with the colons and slashes, rather than the encoded version. The average departmental user doesn't understand that the reason to encode them is for some academic RFC and RDF which is not "liberal in what it accepts". Since the RDF tool has a satisfactory way to encode links, this problem is essentially solved. Therefore I'm changing ckanext-archiver to accept these unencoded links, I'm afraid.
#1683 1326976925000000 dread Here's someone else with the exact sorting problem: http://lucene.472066.n3.nabble.com/last-item-in-results-page-is-always-the-same-td2513423.html
#2722 1343060105000000 shevski Hey, I only mentioned bug 2 here because I'm pretty certain this already exists as a separate ticket. Have definitely reported it before, but i think someone else created the ticket - so just wanted to remind that this hasn't been fixed either yet. What's the best way to do this in future?
#1175 1314030683000000 dread Hi Flavio, is this still a concern? I'd like to close this ticket unless you can provide details of the error from your logs or exception email.
#1183 1311181719000000 thejimmyg Hi John, Can you have a look at this one too please? Cheers, James
#1062 1311178145000000 thejimmyg Hi John, Can you please check that the new webstore+preview works correctly with this one please? Cheers, James
#1150 1311178163000000 thejimmyg Hi John, Can you please check that the new webstore+preview works correctly with this one too please? Cheers, James
#447 1294410666000000 thejimmyg Hi Richard, could you take a look at this please? It is probably invalid now, in which case feel free to close it. Many thanks, James
#1197 1340018903000000 seanh Hi Toby, yes I think I agree with you, it reminds me of when I install new Android apps on my phone, some of them start off by bothering me with some sort of guided tour or long instructional text, I hate this and always skip through without reading it, expecting to be able to figure out the interface for myself. The one thing that something like this could be useful is, rather than showing someone how to use the site, showing them what the site is capable of so they can assess whether it meets their needs/is something they're interested in. However, we already have a good guided tour of this type on ckan.org/features, those pages are really pretty good. Close this as wontfix?
#936 1298283172000000 thejimmyg Hi Wayne, I'm assigning this to you but it isn't a priority yet. We'll put it in a sprint when it is time to do it. Cheers, James
#1401 1320142359000000 rgrp Hi, this is very useful to hear. Can you point out links or even better submit a patch / pull request: http://wiki.ckan.org/Submitting_a_code_patch
#2454 1339493727000000 aron.carroll Hmm, I totally agree with you on the missing username front but it would be nice at least to provide the errors in the same way we do the other forms. Currently it just displays a flash message which is unexpected. I'd suggest we add a generic "failed to login, invalid fields" in the error_summary block. Then more specific "this field is required" when a required field is left empty.
#1400 1331544485000000 rgrp Hmmm. Emerging consensus from discussions in last few months is that wiki is fairly confusing and we should move core, solid docs (from whichever area) to the main docs. Furthermore, key dev info like how to setup and do extensions *is* already in the main docs (see http://docs.ckan.org/en/latest/writing-extensions.html) and has been for 6m+. I've created #2226 for more work on docs and you may wish to comment there.
#2668 1343130433000000 ross Hmmm. dread, are you merging these into master yourself?
#949 1297074827000000 rgrp Hocus pocus so set owner after being fixed!
#214 1263057591000000 nickstenning Hover names haven't been addressed yet. Otherwise mostly done. Closing.
#799 1294232675000000 thejimmyg How can we tell a WAF document has changed, we simply need to re-harvest it to see surely? Moving the issue to ticket #728 to be dealt with together.
#936 1303117147000000 thejimmyg How is this coming on John?
#750 1294408970000000 thejimmyg How would this be done? Is it part of the CSW spec?
#1737 1337942345000000 rgrp I *strongly* disagree re access to solr API -- i don't really care if it is direct but I want something that looks like it at least for core query parameters and facets ... Is there some major issue around security etc (e.g. limiting to only public datasets or similar?)
#2445 1338542340000000 ross I *think* this is done in feature-2445-add-related-new although I may have missed something, if you could take a look and let me know if it is what you wanted.
#2361 1337016768000000 amercader I actually spent some more time of this because I upgraded PDEU to CKAN 1.7, which was needed to fix the search index and a good testing for the release as well.
#679 1294166120000000 dread I added some extra bits in cset:1ca7ba29d409. Resource formats disagree between DGU and the FAQ - have sided with DGU for now as it's simpler. I think this ticket is complete now.
#1477 1324549459000000 dread I added the sub-tickets since this tickets already covers them really. They may provide useful details in the course of doing all this.
#1395 1320857823000000 dread I added this to the instructions a few days ago to fix this issue for the 1.5 release: {{{ pip install webob==1.0.8 }}} Cheers Sean.
#1011 1298821699000000 rgrp I agree that IAuthorizer is useful but not sure how it addresses the requirement of the ticket. AuthorizationGroups are already editable via the web interface at /authorizationgroup
#1104 1303920492000000 dread I agree this should be fixed.
#662 1286991079000000 dread I agree we should not have the 'read-only' things like Ratings in the default returned Package Entity. What do you think of having a parameter to be able to get these if you want them though? Do you mean you *can* re-post the *entity* post response? Not sure what you mean by "An issue for CKAN too."? In addition to this ticket, what do you think about changing the behaviour of the Package Entity PUT/POST, so that you replace the entire Package, not just the fields you specify? So you don't keep left-over values, just because you didn't specify them as null?
#876 1293218714000000 anonymous I agree with all your points about testing apart form using sqlite, especially splitting out the functional tests and continuous integration. > Longer term I agree that it would be better to run local tests against postgres too, but that will I think involve refactoring many of the tests. Well there are two options 1. refactor the tests 2. refactor the code to use sqlite and postress It is a value judgment as to which is more complicated. I personally think 2 is more complicated but may be wrong on that. The real danger with 2 is that you are needlessly adding complication to production code, with 1 you are only changing the tests. Upgrading to sqlalchemy 0.5+ should happen first regardless. You will need upto date documentation. There is another option too. Put the postgres data directory on tempfs/ramfs and turn off durability [http://www.postgresql.org/docs/9.0/static/non-durability.html here]. We would need a way to db init before the tests where run (or) at boot). This may be the best of both worlds. Anyway Happy xmas!!
#1740 1328094884000000 dread I agree with getting rid of {{{from module import *}}} and the approach suggested. However, I really disagree with getting rid of {{{from x import y}}}. In particular we have a strong convention of using this for ckan.model. It is a valuable abbreviation as it is used so much in the logic layer and tests. If someone should accidentally reassign the value of model to something else then I believe it is simple to see what has gone wrong.
#1044 1300382367000000 dread I agree with leaving #1001 solving this issue. Centralising this is good. This ticket can instead focus on: * returning the correct 403 error (rather than the 302 currently) * creating some tests * documenting * consider renaming the SITE_READ variable and rethinking purpose
#940 1296807699000000 rgrp I agree with pudo (though it would not be the end of the world if these were treated as the same realm!). I've now created a permanent redirect for www.ckan.net to ckan.net. {{{ RewriteEngine on RewriteCond %{HTTP_HOST} ^www\.ckan\.net$ [NC] RewriteRule ^(.*)$ http://ckan.net$1 [R=301,L] }}}
#1709 1327620218000000 rgrp I also note there is an error with how importing was working (re top level imports in lib/search.py) that meant simple_search was broken. I've fixed this locally and raised with Ross (whose commit triggered the problem) ...
#2454 1338994536000000 toby I am against providing much more that you did something bad things like invalid username leak info - people should not know if usernames exist. Maybe I'm a bit mean about this. I'd be happier to add some javascript check on the form post that checks for no password etc - maybe that's not so practical
#2440 1339581622000000 toby I am changing this to assigned not accepted as this makes trac easier to use
#324 1274807970000000 pudo I am currently writing a Solr subclass for the search index (#317) and would propose adding standard methods to the ckan.libn.search.Search class: index_package(), index_tag(), index_group(). Those could then be called by a generic queue consumer, irrespective of the used search back-end. I will prototype such a consumer soon, so we should talk to avoid doing some duplicate work here.
#1109 1305124697000000 kindly I am happy this is fixed in cset:445fc04333dd.
#998 1298371191000000 anonymous I am happy to get rid of paster db create altogether as a compromise? Or add a depreciation warning to it?
#1137 1305217449000000 kindly I am not sure this needs to be done. I think we should keep the continuity object always in the table, even if it is deleted. The querying should be done through the logic layer so the deleted state should not be an issue. The clients should be entirely state aware. The only thing that needs to be done is to remove all statefullness of relations. These are the only things that are complicated. This would make vdm just a simple copy on write mechanism, with the client controlling the state.
#1240 1314180488000000 dread I basically agree, but just thought I'd add a couple of comments into the mix. > GET at root returns whole package set (a *bad* idea) Sure it has a cost, but I don't see what the problem with this is if the list is cached. Forcing developers to paging through the list of packages is putting unnecessary obligations. I'd say that the top two RESTful operations are listing objects and getting a particular one, and you'd be taking away one of those. > Unify on /api/v{version num}/... structure Where is it not currently unified?
#1214 1310062621000000 dread I believe "A PUT request without a body throws a 500 Internal Sever Error" was fixed yesterday in the code. (Not deployed to test.ckan.net yet though)
#1467 1326119954000000 dread I believe that the "publisher issue" that James alludes to is that the dump doesn't contain the 'parent publisher' field that is generated in the DGU system on the Drupal side. This information will be stored following the Groups Refactor #1477 and should be added to the dump at this point. Excluding Datasets that are state=deleted is a good idea. I've split that off into #1623 The other issues mentioned are simply data quality - the same whether viewing the dump or elsewhere.
#460 1285443859000000 [email protected] I believe the initial report is incorrect. It states that the status was changed from "active" to "deleted". I believe that it was actually changed from "active" to "None". This might indicate a bug in the code: The value of the status field is lost.
#1452 1340190587000000 ross I believe this has been addressed by Toby.
#1453 1322581830000000 dread I believe this is finished now. This was merged into master in cset:c0aaa31c4b7ded54d and headed for release 1.5.2.
#2671 1345209579000000 toby I believe this is fixed in master/2375
#1258 1319812452000000 dread I believe this was broken with the introduction of moderated edits in CKAN 1.4.3 and this fix went into 1.5.
#1360 1317315031000000 dread I believe zephod has removed these from the UI already. I removed them from the search code, tests, docs and provided suitable guidance in cset:5b20ae1673ea which is headed for CKAN 1.5.
#2691 1342542047000000 shevski I can replicate the 404 error. Follow steps below 1. Click on add a new dataset 2. Name it and put an incorrect character in tag field "e.g. " :" 3. Click on 'Next: Add Data' 4. Error message shows, wipe tag field (i.e. delete " : " until field is blank 5. Click in 'Next: Add Data" again
#700 1288562082000000 rgrp I can verify that groups are getting lost on package preview on ckan.net (steps: 1. click edit, 2. preview 3. look at edit form and group has disappeared). Given this is a bug on a production service it is urgent this gets fixed. @pudo: please can you confirm your expected fix date on this?
#2471 1352206679000000 johnmartin I can't context on this. Closing.
#1701 1330084925000000 dread I can't find these changesets - am not sure which release this is in.
#2446 1352206530000000 johnmartin I can't get access to said project. Can someone please give me access so I can triage this?
#2451 1352206567000000 johnmartin I can't get access to said project. Can someone please give me access so I can triage this?
#2457 1352206516000000 johnmartin I can't get access to said project. Can someone please give me access so I can triage this?
#2641 1352206794000000 johnmartin I can't get access to the project... can someone link me?
#1238 1311583876000000 kindly I cannot reproduce this, to me it looks like it does get the correct revision. If you for example look at the package a millisecond before i.e http://ckan.net/package/osm%402010-11-30%2000%3A21%3A49.627829 the tags are no longer there that were added in that revision.
#1393 1318505854000000 dread I changed this: {{{ diff -r 47657581fc30 ckan/tests/__init__.py --- a/ckan/tests/__init__.py Wed Oct 12 17:58:19 2011 +0100 +++ b/ckan/tests/__init__.py Thu Oct 13 12:29:54 2011 +0100 @@ -373,7 +373,7 @@ plugins.load('synchronous_search') def is_search_supported(): - supported_db = "sqlite" not in config.get('sqlalchemy.url') + supported_db = True return supported_db def is_regex_supported(): }}} But there seems to be a problem finding the package when trying to index it: {{{ ====================================================================== ERROR: test suite for <class 'ckan.tests.functional.test_search.TestSearch'> ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dread/hgroot/pyenv-ckan/lib/python2.6/site-packages/nose/suite.py", line 208, in run self.setUp() File "/home/dread/hgroot/pyenv-ckan/lib/python2.6/site-packages/nose/suite.py", line 291, in setUp self.setupContext(ancestor) File "/home/dread/hgroot/pyenv-ckan/lib/python2.6/site-packages/nose/suite.py", line 314, in setupContext try_run(context, names) File "/home/dread/hgroot/pyenv-ckan/lib/python2.6/site-packages/nose/util.py", line 478, in try_run return func() File "/home/dread/hgroot/ckan/ckan/tests/functional/test_search.py", line 21, in setup_class CreateTestData.create_search_test_data() File "/home/dread/hgroot/ckan/ckan/lib/create_test_data.py", line 66, in create_search_test_data cls.create_arbitrary(search_items) File "/home/dread/hgroot/ckan/ckan/lib/create_test_data.py", line 197, in create_arbitrary model.repo.commit_and_remove() File "/home/dread/hgroot/pyenv-ckan/src/vdm/vdm/sqlalchemy/tools.py", line 110, in commit_and_remove self.commit() File "/home/dread/hgroot/pyenv-ckan/src/vdm/vdm/sqlalchemy/tools.py", line 100, in commit self.session.commit() File "/home/dread/hgroot/pyenv-ckan/lib/python2.6/site-packages/sqlalchemy/orm/scoping.py", line 139, in do return getattr(self.registry(), name)(*args, **kwargs) File "/home/dread/hgroot/pyenv-ckan/lib/python2.6/site-packages/sqlalchemy/orm/session.py", line 614, in commit self.transaction.commit() File "/home/dread/hgroot/pyenv-ckan/lib/python2.6/site-packages/sqlalchemy/orm/session.py", line 385, in commit self._prepare_impl() File "/home/dread/hgroot/pyenv-ckan/lib/python2.6/site-packages/sqlalchemy/orm/session.py", line 361, in _prepare_impl ext.before_commit(self.session) File "/home/dread/hgroot/ckan/ckan/model/extension.py", line 103, in before_commit methodcaller('before_commit', session) File "/home/dread/hgroot/ckan/ckan/model/extension.py", line 38, in notify_observers func(observer) File "/home/dread/hgroot/ckan/ckan/model/modification.py", line 45, in before_commit self.notify(obj, DomainObjectOperation.new) File "/home/dread/hgroot/ckan/ckan/model/modification.py", line 70, in notify observer.notify(entity, operation) File "/home/dread/hgroot/ckan/ckan/lib/search/__init__.py", line 93, in notify package_to_api1(entity, {'model': model}), File "/home/dread/hgroot/ckan/ckan/lib/dictization/model_dictize.py", line 231, in package_to_api1 dictized = package_dictize(pkg, context) File "/home/dread/hgroot/ckan/ckan/lib/dictization/model_dictize.py", line 118, in package_dictize raise NotFound NotFound ---------------------------------------------------------------------- Ran 1 test in 2.734s FAILED (errors=1) }}} Any ideas John?
#2855 1345104178000000 shevski I cleared my cache and it's working now
#263 1277717180000000 rgrp I consistently get sent to google login even though I choose openid meaning I am unable to login!
#276 1271250866000000 dread I could not recreate this. I think it is only for particular packages?
#1285 1323173125000000 thejimmyg I could write some middleware to handle this. Can we come up with a list of exceptions not to catch or should I create a base exception called "NoEmailReportTriggeredException()" which exceptions for this purpose have to be derived from or which code has to raise?
#1532 1323956004000000 dread I couldn't see a way to communicate the situation "OpenID authenticated, but doesn't match any CKAN user" from the repoze middleware to CKAN. So in [release-v1.5.1c 9e86c8b] I have provided extra instructions in the OpenID log-in screen, and in the log-in error message suggest what could have gone wrong. This issue appeared in 1.5.1b and fixed in 1.5.1c in time for the 1.5.1 release.
#937 1297689781000000 sebbacon I did a very quick hacky thing at the end of last week on top of the "insert google analytics code" extension we discussed, to work out "most popular packages" based off data harvested from the Google Analytics API. Needs making generic, tests etc but could be a starting point: https://bitbucket.org/sebbacon/ckanext-googleanalytics/src
#536 1286376029000000 dread I did this a few weeks ago.
#2734 1343061994000000 shevski I did this with a dataset I just created, 5 mins before creating this ticket Tried it again with a new datasrt, happened again. It's when you're editing a resource
#139 1255188974000000 dread I didn't manage to create duplicate tags - must be the old code. I fixed this particular package in ckan.
#989 1297706620000000 kindly I do not think we need to 'extend the model' if you intend to make the migrations separate. If the schema is decoupled, then there are no problems. So each plugin can have its own model and use sqlalchemy independently i.e have their own metadata, classes and mappers. They do not have to even use sqlalchemy. What I mean is that there is no need to do anything apart from. * Agree on a naming convention of the plugin tables (including their own migrate table each) * Agree to the rule that no plugin can add a column to an existing table. * Agree that no table can have a (database level) foreign key constraint between the core tables and itself in either direction. They *can* have implied sqlalchemy level joins. * Maybe have a hook that on db upgrade all plugins are upgraded. Each plugin will have to redefine the tables, classes and mappers they need to join onto the core tables themselves. reusing/extending the core model will not be worth the trouble. This seems to cover your use cases and this way everything is nicely decoupled. Best of all there is very little work to do...
#1784 1328615106000000 dread I don't agree. I think we have a good compromise at the moment, where you have readable URLs, and people can change names if they want to. Names are changed only occasionally. The CKAN site adjusts all its links automatically of course. External blog posts may have incoming links, and these would break, but it's not difficult to search for a dataset. If we're really worried about this then we should provide a 'permalink' somewhere on the Package / Group / Resource page. In the meantime, I suggest changing the Activity Stream links to be with names.
#770 1296593925000000 thejimmyg I don't care about this. It is too trivial. If I get around to fixing it they great but I don't need it logged as a ticket.
#368 1291831811000000 thejimmyg I don't have enough information to debug this problem. I'm assuming that since this has been a while that the problem is solved? If not please re-open the ticket and add your contact details.
#972 1300219509000000 thejimmyg I don't really agree with this. In fact I'd rather move further away from auto-magic key value pairs stored in JsonTypes. Can we discuss on Skype please?
#801 1296593735000000 thejimmyg I don't see why we'd really need to do this. Under the current system a job would be created just before the harvesting would be run so the creation date of the job is (give or take a few seconds) the date of the harvesting. If we moved to a queue system this would be done better anyway.
#888 1307352537000000 thejimmyg I don't think any progress has been made on this for a bit so I'm assigning it to me.
#1343 1316078440000000 dread I don't think email confirmation is necessary - see discussion at #1319
#982 1297525477000000 rgrp I don't think i understand why this has been closed (and it would surely be wontfix rather than invalid ...). Let me explain in more detail: we would move to having one and only one pip-requirements.txt in the repo at any given revision and it would simply have the correct info for whatever branch/revision it was on. At the moment we are having extra pip-requirements-....txt for labelling branch pip-requirements when we could just the branching facility of mercurial. You'd do {{{ wget http://bitbucket.org/okfn/ckan/src/metastable/pip-requirements.txt }}} rather than {{{ wget http://bitbucket.org/okfn/ckan/src/default/pip-requirements-metastable.txt }}}
#2678 1342461370000000 aron.carroll I don't think there's actually any logic in CKAN to let you delete a related item at the moment. So assigning to Toby to take a look.
#1122 1306662099000000 pudo I don't think there's really a nice way to do this with the current solr indexing library, but I've commented out the list handling code which should really make handling this cleaner.
#1085 1302621951000000 rgrp I don't think this is very useful output :) Most of this is test/demo/rdf and therefore not relevant. Also have you checked your ckan.site_url in your development.ini -- which configures where what is used as based for all external urls in the templates? IMO there is nothing to fix here.
#559 1310126313000000 shevski I don't understand this one. It is older than 6 months so marking invalid.
#611 1294408239000000 thejimmyg I don't understand this task, but suspect it can be treated as a duplicate of #569.
#446 1294414077000000 thejimmyg I don't understand this ticket. Since no-one has contributed to this ticket in 5 months I'm closing it.
#1004 1323174597000000 thejimmyg I don't understand. We just had a team meeting about this, all discussed it and agreed to close it. Yes, you get taken to the login page, but that is the correct behaviour. The problem in the past was that the link was in the yellow box and there was no explanation as to why you had to login. This time you click from the header bar and there is a clear message saying "Unauthorized to create a group" - exactly as a user would expect. Even if the exact text of the ticket description isn't fully implemented in the current release, the UX isn't broken anymore. Yes, it might be even nicer to have a message warning them in advanced but these improvements will be taken forward in the UX work - maybe there is an even better solution than a message? Since you are unhappy about closing it I'm marking it as "Duplicate" of #1521. As agreed earlier with the entire team, we'll take this forward as part of the groups refactor. See #1521 for more information.
#274 1287398398000000 dread I fixed the docs a couple of weeks ago. Need to ensure there is a test though.
Note: See TracReports for help on using and creating reports.