1. 4 years ago

    I've had a look at the comments on BdJ.

    I particularly noticed the one about hiding business info.
    I don't know if there might be some value in hiding components on the program - I very much doubt there being many users who use them all but the business side (contacts/resources & etc) does speak to a particular design philosophy and purpose which was a big thing when Do-Org started. But times have moved on and most of this use has now moved online - into the cloud or corporate servers - even for SMEs.
    Personally I see little need for hiding. An unused component doesn't really get in the way.
    But I do see a lot of potentially usable functionality that I don't use because the database items are hard-coded. This is the sort of thing I was talking about when I was looking at the possibility of repurposing with the language options when they come.

  2. Chris

    25 Jun 2018 Developer, Moderator, Test Pilot

    To be honest, I'm not sure I understand the situation. If you don't want to use Contacts, then it can be hidden from the toolbar. Just don't use it. When you don't launch a Contact tab, it doesn't use a resource.

    Always password protect your database if you have business sensitive information in there. If you want to share a database with your family, then make two databases. One for the family and one for the business.

    Perhaps I'm not understanding this correctly.

    People - please enlighten me.

    Sir Scratches Head a Lot

  3. I agree that I see no problem with unused Contacts or any other component.

    What I do see is an opportunity to use Resources (or indeed Contacts) in a different way by having the ability to change the labels.

  4. Chris

    26 Jun 2018 Developer, Moderator, Test Pilot

    That's correct what you say about changing labels.

    When I release the localisation files, you'll be able to rename any of the nomenclature.
    eg: Changing the term "Resources" to "Stash" or "Contacts" to "Connections".
    The database field names in SQL queries and Reports won't change though.

  5. If it is true localisation, I would expect all visible labels to be changeable to the new language - eg in Resources, Product, Short desc, Contact name etc, should be changeable to words that are similarly meaningful in the new language.
    Is this not what you intend?

  6. Chris

    27 Jun 2018 Developer, Moderator, Test Pilot

    I intend to have all visual labels, currently in English, to have a translated alternative. However, if you export the database as SQL there will be original field names, of which are English. This would only affect low level queries though.
    eg: The label "Flag Marker" in the database is called "flag01". The label could be changed to "Vlag" (Dutch) but the internal field name would still be "flag01".

    doogiePIM is packed with English so it may take a few revisions to grab every label.

    I hope this helps answer your question. Perhaps I should start a new "Localisation thread" for this very purpose.

  7. That's fine. It means that repurposing will be entirely feasible.

    For instance, not that I'd thought of doing it, it would be possible for someone playing a RPG (or running a game) to redo the Contacts to contain characters, possessions etc. Or details of the animals if they are running an animal sanctuary. I doubt if many people will be doing a query on an exported database, but they might be motivated to adapt a module if they have a particular need and have no use for the module's original purpose.


or Sign Up to reply!