Topic: Troubleshooting and Bug Reports / FTP?

The reasons given at the time FTP was withdrawn were to do with ‘support’ issues – 37S apparently fed up with people complaining about their (in)ability to configure their FTP connection. To be honest, a pretty lame reason I think. I think the real reasons are more to do with economics – two dimensions of which are:

• It is cheaper to develop features if you have a simpler platform: just as 37S has ‘desupported’ older versions of IE recently
  • Some features of Basecamp only work if you store the documents in S3 – such as thumbnails. No reason why this should be so other than that 37S don’t want to do this.
  • Likewise 37S artificially cramp FTP users – with an file size upload limit 1/3 of that users of the S3 storage. Again not technical reason why this should be so, it is just to annoy people I think.

• The S3 solution as more likely to ‘lock in’ their customer base (so preserving income)
  • AFAIK 37S continue to not provide any sensible information about attachments in the Basecamp XML export – so there is no way of ‘retrieving’ your information from Basecamp short of getting a MacJob worker to go to every page and download all the attachments. As you loose all your stored information if you drop your account (the S3 storage is 37S’s not yours, so reverts to them) – so effectively they can ransom your data should you want to use another system. If you store with FTP, you can ‘get to’ your data directly and back it up etc. should you want to.

Our firm uses Basecamp and likes it. But we’d not be allowed to use it if we tried to join now (our policies don’t allow us to store information on ‘uncontrolled’ storage – minimum test is that we have to be able to back up our information to a location we control). Lucky for us we got in before FTP was chopped.

Topic: Troubleshooting and Bug Reports / Moving from FTP hosting to Basecamp Hosting

FTP access is now apparently only available to accounts that were created before 37S introduced the ‘no FTP’ policy. So if you have joined since, you’ll not find any sign of it I expect. If you do have access, you will find a page to set up the FTP connection under “Settings / File Upload Settings” from the Dashboard view of your Basecamp.

HTH

Topic: Feature Requests / Daylite

We use both Basecamp and Daylite. I’m quite sure if we did a quick poll our users would vote Basecamp as being much the better application.

Our use of Daylite arose because we wanted a mechanism to share contact information between our mac-only network of users. Groupware is a segement that is poorly served by OS X application vendors, and really there were only a few applications that could provide this function. What we really wanted (and still want) was a mechanism that integrated neatly with the OS X address book – so we could then make use of the contact information in applications written to use OS X Address Book – but also allowed for remote connections to our network: many of the available solutions are dependent upon all being on same subnet.

Daylite recently added iSync support, and we were hopeful that it could provide what we were looking for. It does, after a fashion, but it actually is a pretty klunky solution – although the app is OS X specific, it doesn’t have much OS X UI niceness: it looks and acts more like a Win3.1 app that has been reskinned to work on OS X. It has a ‘walled garden’ approach – so expects you to mail merge / email via a built in text editor, track dates via its own calendar, store addresses in its own address book. Support for OS X apps is via an iSync connector. It also claims to link to Pages and Word but only via a laughable script driven approach that does merges via an item by item replace activity looping through address list (takes ages, one doc per merged name). And the iSync support is ropey – so much so we’ve turned it off, and move address back / forth via .vcf export / import. But it is stable – other similar solutions we’ve looked at (e.g. SOHO Organiser) run on similar OpenBase driven walled-garden model, but even less safe when it comes to synchronisation… So we are still with Daylite, and ever hopeful that it will evolve into something better (though rumour is the developers are focusing all their attention on an app for the iPhone… :( ).

Maybe in time someone (?apple?) might come up with a groupware solution that actually works within the OS X environment. But no sign of anything yet. If you (or anyone) comes across such, we’d be interested in finding out about it.

Topic: Feature Requests / Things Integration

We don’t use Basecamp todos at all, not because they don’t work, but because all our various users have their own solutions to to-do management that pre-date our use of Basecamp. So this would suggest if only Basecamp could talk to every todo system, it would then be possible to use Basecamp todos. Since it probably won’t – I suspect it will always be necessary for users to choose to use the todo method of their choice or use Basecamp’s.

My preference is to keep things simple. Things does exactly enough to be useful, without huge mental or organisational overhead. Why would you want to make it more complex by sync’ing with Basecamp…?

Topic: System Announcements / Basecamp interruption of service

Likewise here. Same Get/clients error.

Topic: Feature Requests / File icons

Bump! We’d appreciate this feature being added too – as we too use ODF.

Thanks!

Gavin Lawrie, UK.

Topic: Troubleshooting and Bug Reports / Moving files to Basecamp file storage

While they were at it, it would be great if they included information about attached files in the Basecamp XML export (at least last time I checked they didn’t) and provided a mechanism for you to extract / backup / manage your files from S3 storage once they were there.

I don’t know what happens to organisations that for whatever reason want to move away from Basecamp. But it would appear that there is no easy way to get your attachments back – and if you do they will be separated from the information in the Basecamp message store (as in, you’ll not know where they ‘attach’).

Basecamp should be confident enough in the quality of Basecamp to rely on people staying with them because the product is good – not because they’ve hijacked their data ‘Hotel California’ style.

Topic: Troubleshooting and Bug Reports / Moving files to Basecamp file storage

I’m pretty sure the answer is no. AFAIK 37 Signals don’t provide you with direct access to the S3 area used to store them when you use the ‘plan’ storage, so you can’t FTP them over or such like.

But even if you could that wouldn’t help, as Basecamp stores information about attached files on external FTP servers as ‘hard wired’ URLs. What is more, Basecamp doesn’t seem to ‘know’ about these attachment links after they have been created – if you change a project name or associated with a different ‘company’ (so files get stored in a different place in the FTP server) all Basecamp does is change URLs it uses for new links. All the old links point to where it thought to place them given the old name / company association. It’s really crude (or really simple) depending upon your point of view.

What this means is that if you want to change the location of lots of files (and I’m guessing 15GB is a lot…) you need to find a way to edit the hard-wired URLs that make up all these links. Now given how Basecamp works, there is no way to predict where a file might be stored based on where the link appears in the Basecamp hierarchy, so you the best you could do would be to do some sort of global edit – change the root of the URL to point to some useful equivalent in the S3 storage system perhaps.

This is pretty awkward – since Basecamp don’t provide any access to where the URLs are stored… (are you spotting a common thread here…?). So next best thing would be to do something clever on your FTP server to map HTTP requests for the files to the appropriate location in S3 storage… hmm… but hang on, that won’t work because you can’t access the S3 storage directly.

So, ends up you are stuffed multiple ways. Either you employ someone to manually migrate your entire Basecamp attached files to S3 storage (i.e., one attachment at a time…), or you simply bolt a bigger disk into your FTP server. Almost certainly you’ll be better off simply adding more storage.

HTH

Topic: Troubleshooting and Bug Reports / Photoshop files convert to HTML when downloaded

Just tried here but can’t reproduce.

Files without any extension get interpreted by Basecamp as being HTML files for some reason – are you sure the files had extensions? If not sure, try adding .psd and loading again…

Topic: Troubleshooting and Bug Reports / Amazon S3 down or broken?

Just a thought – but one thing you could do to protect against this type of ‘utility failure’ would be to allow people to go back to using their own FTP servers… at any point some of these might go down, but you eliminate the ‘common mode’ failure that brings down the whole pack of cards.

Topic: Troubleshooting and Bug Reports / Moving from FTP hosting to Basecamp Hosting

It seems this limitation on file URLs being ‘fixed’ in the Basecamp database is one of the reasons FTP access is ‘grandfathered’ in Basecamp. Also, if you start using S3 storage those links will also be ‘fixed’ and you’ll be stuck the other way. If you change FTP servers, you’ll end up with some files on one server and some on the other.

I’ve asked previously about this, but as yet I’ve not found documentation on where in the XML structure used in Basecamp XML exports the file link information is stored – if it is there at all. This makes managing files stored in basecamp quite complex – ideally Basecamp should provide a list of all file URLs so you can keep track of what files are linked to it.

You can get around this limitation by using FTP – as you can simply do a directory listing of the files on the FTP server.

Note that if you give up FTP access you apparently can’t get it back again – so think carefully before you move to S3 storage.

Topic: Troubleshooting and Bug Reports / Backup Basecamp

I’d be interested in hearing any constructive thoughts on this too.

This is the second topic in these forums that I’ve seen people reply, as Justin Reese has, saying effectively that it is OK for Basecamp to fail to meet a client expectation as the whole thing is a bit tricky, and not providing it is really for your own good. It is a novel approach, but for me a bit weak: yes there are boundary issues such as what happens when you run out of undos (or equiv), but to solve this simply by not providing undos is only one of many possible solutions and probably not the best.

The separate suggestion that the XML export feature will solve this issue is also, in my view, a red-herring. There are several postings in this forum (and one in this thread) that indicate that without documentation concerning its structure or use (if there is any, I’ve not found it, so please post a link to it if you know where it is) the XML format is largely unhelpful – and it also appears to leave out information about any attachments to messages, preventing it working as a useful backup anyhow. Further, if you subscribe to Justin’s view that anything even mildly complex is too tricky to implement for Basecamp users, the provision of XML as the backup seems to ensure ‘more hurt than the sickness’.

Hopefully sooner or later someone will come up with a way to make a useful, restorable, backup of a Basecamp account. Until then, I think users of Basecamp have serious risks, as the only option is ‘trusting the system’ to safeguard their data for them.

Topic: Feature Requests / FTP Storage - No discussion allowed?

It would appear that the only alternative currently is to go with something like ActiveCollab and your own server. “Version 1” of ActiveCollab appears to be ready to go, and from what I can tell from various reports about V1 (based on the beta) it is a reasonable alternative to Basecamp – but of course we’ll only know for sure when the product actually ships.

Topic: Basecamp API / exporting files using API

I’d be very interested to know the answer to this. You should be able to do this via the XML export feature – which in theory gives you all the info about your basecamp (including presumably attachments) – if you can work out how to derive attachment information from the XML. I can’t, and I’ve tried asking 37 Signals for guidance, but they’ve declined to answer this question (at all!) so far.

Topic: Feature Requests / FTP Storage - No discussion allowed?

I can’t speak for those with legal / regulatory restraints. But for us our policy is driven by the risk management requirement that we can retain control of our data / meta data without reference / dependence on the good will of a third party. Crudely – we need to be able to keep a complete backup of the data, and be able to reconstruct the service on another server / system if required. The Basecamp system (in theory, but possibly not in practice) allows you to download an XML copy of the meta data, but this meta data is incomplete – it does not contain any of the files stored. AFAIK, 37Signals does not provide independent access to the S3 storage area used to store any files attached to Basecamp, so since Basecamp does not provide mechanism to create archive copies of attached files, nor independent access to them (so we could make our own) we are required to use our own storage that we can back up.

The unsolved bit of our puzzle is the XML dump which does not appear to provide transparent information about attachments to messages – I’ve posted a couple of questions to 37Signals about this and so far got no reply, and we’ve not managed to work out how / where this information appears in the XML. It’s probably there somewhere… but without ability to decode whatever system is used by 37Signals it isn’t much use to us. We’ve tolerated this issue while we work out if it is just us being dim, or if we can get answers from 37Signals. But if we can’t solve this soon, we’d be off to ActiveCollab or whatever second best alternative we can find in the Autumn. This silly behaviour from 37Signals about FTP is probably encouraging us out the door – but we’d be sad to go. We quite like the product, and it seems to be be getting a bit better over time.

Topic: Feature Requests / FTP Storage - No discussion allowed?

Hi Jason. Thanks for the boiler plate. But that’s really not the issue that was being raised in the thread that you blocked and lead to this thread. The issue is what happens to users who cannot use the Amazon storage system? The original posting raised what was a legit point about regulatory issues – and asked for suggestions and advice about what to do about it. I think people understand what you are doing – what is at issue is whether you are going to engage in any discussion about it.

You’ve been artificially discriminating against users wanting to use FTP for the whole time we’ve been using product – with the strange and unexplained limit on upload file size being 1/3 that offered to users of the Amazon storage, and reluctance to explain how the XML version of a grouphub can be reconciled with attachments.

I really don’t see why you don’t just go other way and simply charge these troublesome users who can’t configure an FTP server more to use their own storage… that way could turn an annoyance into a revenue opportunity. (Though, getting a ‘refund’ on the unused / unusable Amazon storage might be also an option… :) ).

Topic: Feature Requests / FTP Storage - No discussion allowed?

We’ve not done any exhaustive comparisons, but there is this blog entry you might find helpful. Alternatively, Google on ‘Open Source Basecamp’ or look at the this Wikipedia entry that lists many.

Topic: Feature Requests / FTP Storage - No discussion allowed?

In a recent thread a legit question was asked about what options open to people who can’t use the Amazon based tied storage options. Discussion was prevented by the thread being locked by an Admin.

We are in same position that original poster is – we can’t use the Amazon storage system for internal policy reasons – and would seem that any further / future development of our use of Basecamp is closed off as a result (we’re OK with existing account, but it seems we can’t change the account or add additional accounts if we want to keep the FTP feature).

Having the FTP feature retained seems like a reasonable / legit Feature Request. I’ve not yet seen any sensible explanation as to why discussion of adding this service back as a feature request is not OK.

Still – looks like there are some Public Domain alternatives to Basecamp coming along . that do allow local FTP storage. Maybe conclusion is 37 Signals is happy to let them pick up people who need FTP. But again – clarification of this would be helpful.

Topic: Troubleshooting and Bug Reports / No more external FTP server

That’s really disappointing. We can’t use AmazonS3 storage rented via 37 signals due to policy reasons – I know there is a commercial value in locking people in to your system, but that lock-in is on the verge of causing us to move to another solution. Would be shame as we are happy enough with the function of Basecamp, (except for the arbitary upload limits and the partial nature of the XML dump feature).

Topic: Troubleshooting and Bug Reports / No more external FTP server

No. I mean this one -

No more external FTP for current customers

With regard to the question – I meant if we open up another Basecamp account – e.g. additional basecamps for our major customers with whom we have several projects. The discussion elsewhere about OpenID seems to be just about this type of scenario. Will the other basecamp accounts allow us to continue to use our own FTP server?

Topic: Troubleshooting and Bug Reports / No more external FTP server

I notice you’ve deleted the original thread on this topic.

We use the FTP service – it was critical in our choosing Basecamp as a tool. Couple of questions:

1) Presumably we’ll continue to be able to use it?
2) What happens if we decide to add more accounts – will we get FTP access on those too?

Thanks.

Topic: Troubleshooting and Bug Reports / Export/download all files

The absence of this feature is one reason why we use our own FTP server linked to our basecamp account. 37 Signals introduce a couple of annoying ‘gotchas’ if you do (e.g. some features don’t work, max file upload size reduced from 30mbytes to 10mbytes), but at least you can get your files easily.

What is harder it seems is working out how these files relate to the basecamp definition – the XML download of the site you can ask for does not appear to have information about what files are attached to messages / projects in it, and getting this information via the API seems quite complex.

Topic: Troubleshooting and Bug Reports / No more than 50 cells in a table?

Is there a limit such as this? I’ve just had to split a 13 row by 5 column table into 2 sections to get the table to render in Basecamp. Looks really odd. Why do I have to do this?

Topic: Basecamp API / Get listing of files / messages / projects?

Thanks! Given that this is probably a bit of information others need too – do you know if anyone has written something to do this yet?

Topic: Basecamp API / Get listing of files / messages / projects?

Does anyone know if it is possible to obtain the following information via the API (or any other route).

• Name of message to which it is attached
• URL of message on basecamp

We hoped that this information might be included in the XML dump of a Basecamp – but apparently not.

Suggestions / ideas anyone?