Hi Gary, On Mon, Aug 13, 2012 at 6:18 AM, Gary Martin <[email protected]> wrote: > Hi Anish, > > I've uploaded a mockup image to the wiki [1] which covers most of the items > raised in this thread: > > - a new security section (that should only be shown if there is lease > information) > - lease number of days remaining > - lease absolute expiry date (date string should use correct formatting to > display locale date format) > > Did I miss anything? >
Looks fine to me. Thanks! > Regards, > --Gary > > [1] > http://wiki.sugarlabs.org/go/File:Settings_About_My_Computer_Security_Section_Mockup.png > > On 7 Aug 2012, at 17:55, Anish Mangal <[email protected]> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi Daniel, >> >> Thanks for replying! >> >> On Tuesday 07 August 2012 10:12 PM, Daniel Drake wrote: >>> On Wed, Aug 1, 2012 at 1:12 PM, Anish Mangal >>> <[email protected]> wrote: >>>> One problem they were also trying to get around in Paraguay is >>>> that during vacations, the kids don't go to the schools and hence >>>> the leases expire. If the kids also know about this information, >>>> then they can easily make sure that they don't get 'locked out' >>> >>> You'd hope that the project would make provisions for long-enough >>> leases to be supplied before the vacations. But I can see the use >>> for this for when that doesn't happen (which is understandable >>> given high workloads and so on). >>> >>> Talking more with the team in Nicaragua, this functionality would >>> be useful for them too. Similar situations are occuring here where >>> laptops were activated for a certain amount of time, with the >>> strong expectation that internet connectivity would become >>> available in the schools before the activations expire (so that >>> they can be automatically updated/renewed). These expectations look >>> like they won't turn out to be true :( >>> >>> So a manual activation update process will happen and the ability >>> for someone less-technical to be able to quickly check whether this >>> manual update process has completed OK would be of value (that >>> would be the person's only contact with activations - we aren't >>> expecting them to be able to solve any problems if the results are >>> bad, other than report up the chain). >>> >> >> This is exactly the kind of clear info that should have been in the >> feature page in the first place. Sorry for not doing it earlier. >> >>> Anyway, the use cases you describe in your mail don't seem to be >>> described on the feature page. Could you please extend the feature >>> page to go into more detail about this? I'll then add the above >>> local case if its of interest. >>> >> >> +1 >> >>> >>> Why is the proposal to show the number of days remaining? >>> >> >> Yes, I remember discussing specifically this with Roberto (PyEduca >> Technical head) back in Dec 2010, and my suggestion was exactly the >> same (to display the date). >> >> However, as per them (and I know this is not a rational explanation), >> they wanted us to display "no of days remaining". >> >>> The Nicaraguan team have expressed a strong preference that this >>> should (instead, or additionally) display the expiry date. When >>> dealing with long duration activations, which is often the case >>> (until good connectivity is established), having a teacher phone up >>> and say "there are 137 days remaining" (and then having to >>> calculate the day of expiry in order to put an appropriately timed >>> school visit on the calendar) would be a pain. >>> >> >> I agree with this, and since I cannot seem to remember exactly why >> they wanted it to display in terms of no. of days remaining, I'll ping >> them or we can go with this. >> >>>> Since this feature is only relevant for the XO at the moment, >>>> making use of the bitfrost API would be acceptable to me, but I >>>> don't see a lot wrong here by parsing the lease.sig directly. >>>> This file is supposed to be automatically generated/updated in >>>> normal use cases. >>> >>> Are you planning to parse sig02 (delegated leases) "by hand" as >>> well? What if the lease is corrupt in some way? >>> >>> I can see myself objecting to any implementation of this that >>> doesn't reuse bitfrost. It takes care of all of the corner cases >>> and will avoid code duplication. >>> >> >> Again, it seemed to solve the use case we had in Paraguay, and the >> idea behind upstreaming a feature is that it goes through this process >> of review. I am up for changing the code to use the bitfrost api. It >> should not be complex (if it's adequately documented somewhere). >> >>> Daniel _______________________________________________ Sugar-devel >>> mailing list [email protected] >>> http://lists.sugarlabs.org/listinfo/sugar-devel >>> >> >> >> - -- >> Anish Mangal >> Dextrose Project Manager >> Activity Central >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.12 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iQEcBAEBAgAGBQJQIUh6AAoJEBoxUdDHDZVpEX8H/j5oCzGUvnfIWdy1f/awAnkf >> Trtsm4Me8r2D0ufxEyIZkUHugCQPUTdPqDEAlexr8ziQjy8mqNLrbvEWwwxxl4ho >> XstY7RZsk9gPGVYiE1bLniIZnO5e63lIyBEkM3eNgkHrO8XTPw86lBBcTcx9XDrx >> T00HW8J1UGDMo29SRcrnxnNVd6j+uArJXcaeSXhLAPb3xkaharF22AbTlWgQ+4s5 >> YIzvIfmEYMpqXbCCY+IPSVxzcpdRuHhueaFKchDfzRm01Wf77laACUg6+ZFkq/Ft >> 9ChV1LNekysQwf+yCZ9dB9HZdfIjjJ4m1WjrPhrQtqruevs9/nglTp2djqsPU00= >> =QHV1 >> -----END PGP SIGNATURE----- >> _______________________________________________ >> Sugar-devel mailing list >> [email protected] >> http://lists.sugarlabs.org/listinfo/sugar-devel > > _______________________________________________ > Sugar-devel mailing list > [email protected] > http://lists.sugarlabs.org/listinfo/sugar-devel _______________________________________________ Sugar-devel mailing list [email protected] http://lists.sugarlabs.org/listinfo/sugar-devel
