[Sugar-devel] [DESIGN] Proposal: Lease expiry information display in My Settings -> About My Computer

[Gary Martin]

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?

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 <anish at activitycentral.com> 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
>> <anish at activitycentral.com> 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 Sugar-devel at lists.sugarlabs.org 
>> 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
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel