Open-event-server: pentabarf, ical, xcal implementation not working

Created on 5 Mar 2017  路  6Comments  路  Source: fossasia/open-event-server

The ical, pentabarf, xcal implementations are linked in the "Export" tab. Currently using the links, e.g. https://eventyay.com/e/45da88b7/schedule/calendar.ics shows an error page.

bug rest-api

Most helpful comment

@niranjan94 @shubham-padia in this case like you said we should use it in all possible places where sending signals would be a better way of doing it and replace function calls such as trigger_notification calls

All 6 comments

Related to #3586

From https://github.com/fossasia/open-event-orga-server/issues/3586#issuecomment-301301344.
I am thinking of implementing signals to send a signal everytime an edit occurs related to an event (change in event, speaker, sessions, etc ). If this seems okay I'll setup seperate signals for speaker update, sessions update etc. (for potential future use)
@SaptakS @niranjan94 @magdalenesuo What are your opinions about this ?

@shubham-padia I am a little confused. Though it will make things a little more structured and maybe can be used even for triggering notifications and emails, but then again it would add yet another dependency and I think I and @niranjan94 were already planning to reduce the dependencies. Because dependencies can later lead to many troubles in case some bug appears in the dependency itself. Like we faced with eventlet. So I have mixed opinion about this. I do agree that it will make much of the activities more structured and we can use it in many other places as well. But I am not sure whether it is worth adding a new dependency. @niranjan94 your views?

@SaptakS
IMO Problem with dependencies are generally a one-off case e.g with eventlet, while the bigger problem at hand is the constant bugs we are facing, and sure strict testing in future will prevent that, but a more structured code will really help in that. Both the approaches have their ups and downs I think. Let's wait for what @niranjan94 thinks.

@SaptakS I agree with your argument regarding dependencies. We should cut down on dependency. But I think this is worth it.

@shubham-padia you can go ahead with implementation of signals. This will surely make the code more maintainable and structured.

Next steps would be to make maximum use of it everywhere. Some of the place we can use this are :

  • Sending emails after session submission, ticket purchase, etc
  • Generating schedule in xcal, ical, pentabarf after event edit
  • Triggering notifications
  • Clearing and regenerating caches if any related data changes

Please create appropriate issues too @shubham-padia

@niranjan94 @shubham-padia in this case like you said we should use it in all possible places where sending signals would be a better way of doing it and replace function calls such as trigger_notification calls

Was this page helpful?
0 / 5 - 0 ratings