On Sun, 2007-02-25 at 08:15 -0500, Karoly Molnar wrote: > There's only one question left unanswered for me. What are the hard > coded functionalities regarding to the connection between the account > type and the accounts. More directly the same question when an account > type is changed what happens with an account which is based on that > account type.
The details of this will be worked out when I implement it, but I'll outline my plans below. > Lets say that I create two FTP accounts and I modify the launcher on > one, the other stays untouched. If I modify the launcher on the ftp > account type the modified account is still going to represent the > modified launcher. And the one which was untouched is going to use the > new default account type launcher. Is this right? Yes, that's right - custom launchers will be preserved when you change the account type launcher. > Other example what happens if I modify a field name on an account type > that is going top be reflected on all account connected to that > account type except the ones where that field was removed or renamed. > Is this right? Yep, right again. > What happens if I delete a field from an account type? Is the field > going to be deleted from the accounts regardless that there might be > content in it? Yes, the field will be deleted from all accounts, of course after warning the user about this. But we might include an "Only delete empty fields" checkbox in the warning dialog, which would remove the field if empty and convert the field to a custom field if it has any contents. > There are many other use case scenarios where I'd have question. I'd > appreciate If you could clarify what functionalities are going to be > hard coded for the account type change if any. For account type changes, it would be something like this: - Add field: also add the field to all accounts linked to the type. - Edit field: edit the field on all accounts linked to the type which has this field (ie, where an individual account didn't have the field removed). - Remove field: remove the field on all accounts linked to the type which has the field, optionally with a choice to keep fields which have content (converted to custom field). For individual accounts: - Add field: adds a custom field to the account, completely independent of account types - Remove field: removes a field from the account (both custom and type-specified fields can be removed) - Edit field: changing the name or datatype of a type-specified field will convert the field to a custom field - ie, same as add custom field and remove type-specified field. Common data: - Launchers: when launching an account, first check if an account has a custom launcher - if so use it, otherwise use launcher from account type if any. Changing the account type launcher won't directly affect any of the accounts (or custom launchers), since the only change is on the account type - any custom launchers will continue to exist as they were. - Icons: icons are only stored for the account type, and cannot be overridden by individual accounts. This is because the icon is the primary means of identifying the account type. > Possible example where I could use the file field: > - - Storage of my OpenVPN keys. > - - Storage of my encrypted home folder key files. If I'm not mistaken, these would need to be stored in the file system in order to be used by the applications. Why should we store them in Revelation as well? Hm, when thinking about it, I could actually have a use for this myself too - to store X509 certificates, certificate signing requests, and private keys for them. > Thanks again and let me know how I can contribute, Great :) Well, if you want to write code it's probably best if you wait until the basic new account infrastructure is in place, as it will have major changes to most of the codebase. But you could have a look at bugs or features in the issue tracker and start planning how to implement them. Also, there are requests for import/export of many different file formats in the issue tracker, so if it sounds interesting you could start by reverse-engineering some of the file formats and writing incomplete importers (ie, load the data from the file and just print it to screen, then implement account creation etc when the new account system is done). Other than that, translations are welcome. Documentation would be nice as well, but there's probably no point until 0.5.0 is released, because of all the UI changes it would introduce. -- Erik Grinaker <[EMAIL PROTECTED]> http://erikg.codepoet.no/ "We act as though comfort and luxury were the chief requirements of life, when all that we need to make us happy is something to be enthusiastic about." -- Albert Einstein