[Mailman-Developers] mailman-bundler-3.0b1 error - Does it have an HTTPS login page?
Hi, After installation of mailman-bundler-3.0b1 according to the instructions in README.rst and running the web interface, the web server runs and responds HTTP requests. The problem is that when I click the Login button on the top right of the page, I am redirected to this url: https://localhost:8000/archives/accounts/login The server naturally doesn't respond to this, as its an HTTPS request being sent to an HTTP server. I tried some hacks, but could not get it working (I don't know django at all). How can I solve this? Why has this happened? Bests ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Translation
Guillaume Libersat writes: > I've done exactly what you said (splitting commits between effective > translation work and code/template instrumentation) and submitted a > Merge Request there ( > https://code.launchpad.net/~glibersat/postorius/i18n-french/+merge/240066 ). Thank you! My, that was fast! > I hope it's gonna be merged soon :) Me too, but I don't "own" that repo. Florian? Terri? Can you review soon? Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Translation
Hi, Le 16/10/2014 02:49, Stephen J. Turnbull a écrit : > AFAIK Mailman in the past has given free reign to the translators on > existing translations, but adding new translations (if I understand > what you mean by "adding 'trans' tags") is subject to review by other > developers, and eventually Florian and Terri. I don't know if it > applies to the Postorius code, but I know I've run into situations > where it was undesirable to use the internationalization mechanism to > translate certain strings. > > It is very helpful to the maintainers when reviewing and integrating > if you make separate commits for the translations themselves, and for > changes to the originals. It's even better if you keep separate kinds > of changes in separate branches. (This is very cheap for Launchpad; > they use "stacked branches" to minimize the work done to create a new > branch.) > > It occurs to me that if you are adding new translations, it might be a > good idea even to do a separate commit for each one, including both > the markup at the original string and the French translation. > > Note that I'm not a Postorius maintainer, nor the project lead, and > I've also not done translation work myself. So I don't know how much > burden these guidelines put on you. They aren't "rules" (at least not > until Florian or Terri says so!), but it would be helpful to the > project if you consider using them in your work to make the > integration side go more smoothly. > > Thank you for your consideration, and thanks again for the > translations! > I've done exactly what you said (splitting commits between effective translation work and code/template instrumentation) and submitted a Merge Request there ( https://code.launchpad.net/~glibersat/postorius/i18n-french/+merge/240066 ). I hope it's gonna be merged soon :) Cheers, Guillaume -- http://sigill.org ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] mailman.client and UUIDs for user.user_id
On Oct 29, 2014, at 05:27 PM, Aurelien Bompard wrote: >Hmm, to me the current situation is more confusing, since the user_id >property I get from the REST API is different from the one I find in the >database. It's really the same value, just a different representation of it. The conversion UUIDs to integers is completely reversible. >I guess it depends on the reason the UUID is serialized. If it's to avoid >being messed up during the transport, it's a transport issue and I think the >library should convert it back (but the original ascii string should not be a >problem so it's probably not that. Anyone remembers why the REST API exposes >the int value instead of the string? It happened in commit 7043 but the >reason is not given in the commit message. I don't remember exactly why I changed it to the int representation, but it could have been some limitation (valid or not) on restish. The log message doesn't describe that because IIRC, the REST API change happened at the same time that internally user ids were changed to UUIDs. So I probably tried a few things and settled on ints before I committed that change. I could have been trying to optimize the wire format, given that UUID.int is 16 bytes whereas UUID.hex is 32 bytes. Or maybe I was just being dumb. (Not mutually exclusive with the above. ;) We could certainly change the JSON for a user to return the string (specifically, UUID().hex) but we'd need to return both for backward compatibility, if we care about that. Maybe we don't if we're just promising for now that mailmanclient is the level of API guarantee, and we make both changes at the same time. I can probably figure out how to accept either ints or hex strings as input for identifying the user, but it might be tricky. So Aurelien and Florian, what do you think? Should we use the hex representation of the UUID and should I keep backward compatibility. Cheers, -Barry ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] mailman.client and UUIDs for user.user_id
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/29/2014 05:27 PM, Aurelien Bompard wrote: > Hi Florian! > > I think mailmanclient should not expose a different value as the > REST API does (the fact that it's an int representation of a uuid > isn't exactly obvious from the outside, so a non-explicit > conversion could potentially lead to some confusion). > > > Hmm, to me the current situation is more confusing, since the > user_id property I get from the REST API is different from the one > I find in the database. Yeah, I know what you mean. From a Mailman-developer's view that *is* confusing. But the view of non-MM dev, who is just a user of mailmanclient and/or the REST API (and doesn't know the innards of Mailman's database) might be different. If the user_id value changes depending on whether you are using the API directly via HTTP or through mailmanclient, that might be hard to understand. > I guess it depends on the reason the UUID is serialized. If it's > to avoid being messed up during the transport, it's a transport > issue and I think the library should convert it back (but the > original ascii string should not be a problem so it's probably not > that. Anyone remembers why the REST API exposes the int value > instead of the string? It happened in commit 7043 but the reason is > not given in the commit message. Good question. @Barry...? > But how about we add a `uuid` property to the user object which > exposes the original uuid value? > > > Not sure that's useful, converting it back to an UUID is easy > enough ( uuid.UUID(int=value) ) OK ;-) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUURfsAAoJEEceGbPdavl7IxcIAKSp3XQdIW7jyzO67cqsf2+O Q7hXqttQdXCxYriu/BfihOrc+REVihMnE78Hb2JRq/mTc1Waa7wHIEQyM9SAUB+A 9y+oZb75GHrVPONNd89Xs5PODpyjOuFLrg+no4zHRr/CTrH6wgLrQC5EoNgjQsla dN25XAvVNGt2x9uJqLiaETwj7nE++wE8SdlhOlVT+PDZfktPPztCfO4n7TzV2BlU eTUNAxqMKaypd3IjpXpsY8tFUMQKJmilqaja2vXjk067KskPPD48C2CAcSybpWbC LOp8KWW3Uhxi+eHyLWvaqP24MbE92ic5TOmVVVK6926pPAs1uUM7PjR72Xk6dIA= =as2h -END PGP SIGNATURE- ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] mailman.client and UUIDs for user.user_id
> If the user_id value changes depending on whether > you are using the API directly via HTTP or through mailmanclient, that > might be hard to understand. > Ah, very good point. I'll do the conversion myself then I guess. A. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] mailman.client and UUIDs for user.user_id
Hi Florian! I think mailmanclient should not expose a different value as the REST > API does (the fact that it's an int representation of a uuid isn't > exactly obvious from the outside, so a non-explicit conversion could > potentially lead to some confusion). > Hmm, to me the current situation is more confusing, since the user_id property I get from the REST API is different from the one I find in the database. I guess it depends on the reason the UUID is serialized. If it's to avoid being messed up during the transport, it's a transport issue and I think the library should convert it back (but the original ascii string should not be a problem so it's probably not that. Anyone remembers why the REST API exposes the int value instead of the string? It happened in commit 7043 but the reason is not given in the commit message. > But how about we add a `uuid` property to the user object which > exposes the original uuid value? > Not sure that's useful, converting it back to an UUID is easy enough ( uuid.UUID(int=value) ) A. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] mailman.client and UUIDs for user.user_id
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Aurélien, On 10/27/2014 04:36 PM, Aurelien Bompard wrote: > Hey folks, > > Mailman stores user_ids as UUIDs in the database, and they are > converted on the fly to integers by the REST API. However, the > mailmanclient library do not convert them back to UUID. Do you > think this is something that it should do, or should I handle this > conversion in my own code? I think mailmanclient should not expose a different value as the REST API does (the fact that it's an int representation of a uuid isn't exactly obvious from the outside, so a non-explicit conversion could potentially lead to some confusion). But how about we add a `uuid` property to the user object which exposes the original uuid value? Florian -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUUObFAAoJEEceGbPdavl7GsgH/2PsrcCdwKCMcOWAqsci0XYN 458TrvIbgRolMMlW9RogMgcavNJUSaWwB9nSjjU3UV6Z2bCbRJEhBXSce6tNEbJF XZZ5Cdy8I7gGXhfmeP1/+enDSO+lB655KngXBZdhP1IeYME49z1yJnqH6bafsM1e 9YOecu0nVvjUFbpMwVdJVVPhcml0D/qVIcN0wD5ZXfO01m+bx2yTt2cuUkrj7SMt b756OQIcYIBJW3rqr+5kTr/FDCbsN1TrH921k8ZcgthfxMpmYeSwueeIizjFyf0H VAxa83l4uLyzK1LDtXZ4mkimMHIQhSvpGNSJdhPBVLW8oGomnqpPSdu/w/l5KtY= =Lyma -END PGP SIGNATURE- ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
