I am working on creating a dashboard which would access Redmine project data. This dashboard will be a consolidation of project data (delivery date, manager, start date, total issues, open issues, closed issues, bug count etc.) for all projects in the Redmine database.
Any ideas on how to do this? An SQL query to achieve this would be a good start. I have Redmine setup on my local system and can access the Redmine database.
I plan on creating an HTML5 .Net based web application. Once I figure out the queries to be used, I would write an IIS (or REST) service to fetch the desired data from the Redmine production database.
Any help/pointers would be deeply appreciated.
Regards,
Pranjal
You have basically three options:
use the REST API
develop a redmine plug-in
do some custom SQL stuff
REST API
The best you could do is to use the redmine REST API. Using it, you can fetch the data directly from redmine without any SQL queries or manipulating the server. It should even work when the redmine server is updated.
Redmine Plug-in
The next best thing is probably to develop a redmine plug-in. Your plug-in can access redmine classes (Project, User, etc.). For example, you could do something like Projects.all.map {|p| [p.id, p.identifier]} to get the id and identifier of all projects in an array. This approach is way more powerful than using the REST API, but you have to modify the redmine server (install and maintain your plug-in). A plug-in is probably more fragile when redmine changes internal structures, than the REST API.
Custom SQL stuff
I do not recommend developing custom SQL solutions, but it is an option. Such a solution is harder to develop, more fragile, harder to set up, but might offer better performance.
You can see the the redmine database structure listed in db/schema.rb. Having the right schema, you could develop your custom SQL queries and return them to your dashboard.
Think about security
Apart from the usual security stuff (which you should consider too :)), remember that redmine has a rich permission system. Consider which object you make (publicly) available. This is most important for the last two options. When using the plug-in approach, you should have a look at the User#allowed_to method.
With the little information I have about your requirements, I have the feeling that you should go for the REST API.
Related
I'm currently working on a project which would require some realtime functionalities such as Multi-user chatrooms etc.
Ideally, I’m looking to have meteor run the chat application(on a different port) and mongodb act as message broker to the django back-end which would take care of user registration , management and everything 'non-realtime' related.
This would involve setting up a reverse-proxy which would redirect to a different port based on the url (please let me know if i'm wrong in this)
Would this be possible(or even advisable)? Another option would be to implement the same with tornado. but I have no experience with building tornado-based apps and rather do this with a framework I’m comfortable with.
Thanks,
You can have Django serve the Meteor front-end while providing access to its data using django-ddp, giving you some distinct advantages:
Continue to serve your existing Django project/apps.
No extra services or ports to manage.
Scale out by simply adding more front-end Python/Django servers (server to server IPC is done via the existing database connection).
Use django.contrib.auth user accounts in your Meteor app.
Familiar Python/Django code (no "callback" style such as with Tornado).
Use time-tested, trusted relational databases.
Use Django migrations to effectively manage schema changes.
There's a Gitter chat room where I can give you assistance if you need it.
DISCLAIMER: I'm the author of django-ddp.
A meteor application is more than capable of handling the user registration flow and many other things. Why not just build the application entirely in meteor? Your application sounds like a perfect candidate for meteor, with realtime interaction with your database at the core.
The other option would be to use swampdragon which adds realtime data binding within django. It allows for simple bi directional communication between the server and the client. Again, essential for a chat application. It nice and easy to get setup and running as well.
Are there any specific reasons to not implementing your application in one framework alone?
I am planning to use open source gamification - rails based Gioco gem to for enteprise productivity and collaboration applications. I am starting with Sharepoint. While I have supporting material for gamification strategies and use of commercial software apps such as Badgeville, how can I integrate using REST/JSON API with Sharepoint?
Ideally I am looking to generate points on the gamification when users tag, upload, comment on Sharepoint and Yammer. So user action should trigger the REST API.
RedCritter has pre-built integration with SP2013 which is very easy to deploy. There are also pre-built integrations for workflow management tools like Nintex to reward granular behaviors within SharePoint.
https://redcritterconnecter.com/solutions
This is going to be tough. There are far too many places in SharePoint you'd have to handle. While SharePoint does have various event handlers which you can hook up to trigger your code, they would have to be installed farm-wide in all sites, all lists and document libraries, independently. Then you would have to somehow hook up various web parts.
Alternate strategies:
try to handle everything client-side in JavaScript — tedious in nature, error-prone, can't catch everything (e.g. Office integration beyond reach)
turn on auditing everywhere and generate info from audit logs — will be behind in time in respect to user actions, won't catch everything again (e.g. various user interface operations that don't trigger audit records)
In any case, your SharePoint farm admin won't fall in love with this. Most likely you will cause them a lot of troubles and headaches, not speaking about unwanted interferences with 3rd party solutions deployed on the farm.
My recommendation: don't waste your time, it's not worth it.
I would have to agree with Ondrej - SharePoint is fully of proprietary functionality that will be a challenge to work with. I know you had your heart set on going open source, but I know that Badgeville specifically has a SharePoint connector which might get you what you need.
http://badgeville.com/products/integration-catalog/badgeville-for-sharepoint
I'm using Geonames.org for textbox auto-complete. Very neat feature.
They provide both the database and a REST endpoint, something like this: http://api.geonames.org/postalCodeLookupJSON?postalcode=6600&country=AT&username=demo
However, as per the requirement (decrease auto-complete latency, eliminate external resource dependency) I wish to host the database on my server. Geonames provides the database for export, which is nice. However, then I'm facing a task of writing my own REST service solution for accessing my database with imported geo data.
At the same time, I don't think I'm the only person facing an issue like this, so I was wondering what your takes on this are? What's the fastest, the best solution would be in this situation? Is it really necessary to write a REST service from scratch? Or is there a library for that, and I just can't find it?
Environment: ASP.NET (but it's probably going to be a separate web-application anyways, so I'm open to other offerings such as Node.js, Ruby on Rails - whatever will be the least development time).
I'm writing Django application (social network) and thinking about dividing monolithic project to two projects: UI and API. For example, Django will be used only to render pages, interacting with and taking data from API, written on web.py.
Pros are following:
I can develop and test API independently.
In the future, other UI can appears (mobile, for example), it will require service.
I plan to outsource web UI developing, so, if my application will have two modules, I can provide outside only UI one, not sharing logic of application.
Cons are following:
I'm working alone, and developing two projects are harder, then one.
I will not be able to use cool Django admin panel. I will need to write my own.
web.py is more low-level comparing with Django.
It's like a brain dump, but I will be really appreciated if you share your experience in creating web application with UI module and independent API module.
Update (more specific question, as Mike asked)
What Python framework will you use for creating REST API of social network, which can be used by different client applications? Is using web.py that returns JSON only and rendering it by Django for web is good idea?
Thanks,
Boris.
I've been in a situation similar to yours. I ended up writing both, the UI and the API part in Django. Currently, I am serving them both out of the same process/project. You mentioned you wanted to be able to outsource the UI development, but do hear me out.
In the meantime, I have used django-piston to implement the RESTful front end, but a bit of preparation went into it:
Encapsulate all DB and ORM accesses into a library. You can do that either for your entire project, or on an app by app basis. The library is not just a low-level wrapper around your DB accesses, but also can be for higher-level 'questions', such as "all_comments_posted_by_friends()" or something. This accomplishes two things:
You can call your pre-canned queries from UI views as well as API views without having to re-implement them in multiple places.
You will later be able to replace some - if not all - of the underlying DB logic if you ever feel like going to a NoSQL database, for example, to some other distributed storage model. You can setup your entire app of this ahead of time, without actually having to worry about the complicated details of this right at the start.
The authentication layer for the API was able to accept an HMAC/token based header for programmatic access and normal Django auth. I setup the views in such a way that they would render plain JSON for the programmatic clients (based on content-type), and would render the data structure in HTML (with clickable links and clickable docstrings) if browsed by a human from a browser. This makes it possible that the API is fully explorable and clickable by a human without having to read any docs, while at the same time it can be easily processed by a client just via JSON.
On effect, the database layer I build serves as the internal API. This same database layer can be used from multiple applications, multiple processes, if you wish to do so. The UI views and the REST views were both implemented in Django. They can either be in the same process or in separate processes (as long as they have access to the same database right now).
I was hoping to get some suggestions on some best approaches to develop a multi tenant Django project on Google AppEngine.
Some Thoughts to Consider.
I would assume using djnago.contrib.sites is a must.
I would like to use existing applications such as django-profiles and django-registration, I know their models would need porting.
Can multiple domains be pointed to the GAE App and the site be automatically chosen from the request headers?
IF not multiple domains, is there a way to say take a request say to www.example.com/tenantA/login and www.example.com/tenantB/login and push them to one view but with knowledge tennant without changing all the views, maybe using custom managers to hide the complexity from the views.
Generally hoping this will be a discussion of any approaches you have taken in the past or plan to take.
Looking forward to any Comments/Answers.
Regards
Mark
I can answer the App Engine questions for you, though I don't know the Django ones:
Yes, anyone can point a domain to your app using Google Apps, with the 'add services' option, entering your App ID when prompted. You can then check the 'Host' header to determine what site you want to use.
You can hide information per-tenant by using hooks to automatically insert the host in entities and queries: http://code.google.com/appengine/articles/hooks.html
Today Google released SDK 1.3.6, which includes multi-tenancy baked right into the solution.
http://googleappengine.blogspot.com/2010/08/multi-tenancy-support-high-performance_17.html