Zotlabs|Hubzilla Development

Europe, Thu, 23 Apr 2020 18:50:40 +0000

!Zotlabs|Hubzilla Development
@Mario Vavti
@Max Kostikov
@Mike Macgirvin
@M. Dent
Please can you suggest how I should prepare a pull request about Hz 4.6/4.6.2 (based on prod) vs. dev.
For the update db, prod is currently _1234 and dev _1236, while I'm using _1235 at the moment. Or, asking another way, do you push on day _1235,_1236 from dev to prod as well and continue on both branches with _1238?
Before I do anything, will just check conflicts against dev
And, what do you think about a prod 4.6.x vs 4.7.x ?.

invite register update

Mario Vavti

Thu, 23 Apr 2020 19:19:36 +0000

Please only make a PR to dev at this stage. If you require a DB update this should be _1237. Everything else will be messy...

qms (qualified message source)

Hilmar R (u-462)

Fri, 10 Apr 2020 11:54:25 +0000

In the UI dialogs of Invite, Register, Configurations and Notifications you can see some oddities, such as

ZAI0107I, Invitations we are using: 5 / 50

I would like to explain these and enrich them on the occasion of the current domestic ties with the help of small episodes from the longer past. In the middle of the 90's of the last millennium Microsoft released the OS WinNT 3.5/3.51. This was not a complete composition of the company's own, but had interesting functionalities of another operating system, the VMS from DEC. VMS was a popular and powerful operating system for users, with authorizations, a domain concept, guidelines, and much more. The idea of implementing VMS for the PC architecture could not be realized at DEC, and some "escaping" developers were gladly accepted by Microsoft. ( https://web.archive.org/web/20020503172231/http://www.win2000mag.com/Articles/Print.cfm?ArticleID=4494) There was still a fairy tale about VMS, that when some companies moved, the people in charge asked where the systems were actually installed, which led to the realization that their systems had been forgotten in the basements of the old buildings, but continued to run trouble-free even without maintenance. Indeed, the stability of the DEC VAX machines and VMS was legendary. Well, as I said, some things have been incorporated into WinNT, and are present in today's Win systems (which should not lead to the conclusion that the quality of Windows is anywhere near as good as that of VMS). Documentation on WinNT was published by Microsoft Press at the time. There was also a thick book about messages and notices about WinNT, which was translated into German, and cost about 60€ compared to today. The scoop was: the texts were documented in German and sorted according to the English original messages.So the background of a message was not even easy and quick to look up, not to say largely useless.

For decades, operating systems from IBM were widely represented globally. There was also documentation on the messages and the mostly in several volumes of many thousand pages (and much more expensive). And a message, no matter in which language, could be found easily. Each Message item had a short identifier that quickly showed experienced users which corner of the operating system the message item came from. This has advantages for the users, also for the developers. Instead of endless discussions about the message "Your input contains an error", an "IEC1234E blah blah" could quickly lead to an explanation. Interestingly enough, these documentations ("Messages and Codes") could even be skimmed well sequentially to get a better understanding of the operating system functionality.

Identifiable messages in complex systems are not only helpful, but can also contribute significantly to the user-friendliness and transparency of a system. A developer who somehow gets the message "XYZ12345A Blah blah" wrong will quickly know where in the code something about it can be found.

And Hubzilla/Zap? Well, many people here in the forum have been dealing with the system for many years and some of you may remember how difficult and opaque it was to get started. With about 2700 php scripts it is also not a lightweight and the functionality is potentially so powerful that an increase in transparency in general can be helpful. For this reason I used the messages in the Invite and Account functionalities. The additional coding effort is not expensive. A message ...t('This is an error')... might look like this: ...'ABC1234 ' . t('This is an error')...

The message identifiers are structured: Prefix+number+Suffix. As prefix I used 'ZAI' and 'ZAR', where Z stands for core functions, A for account, I for Invite and R for register. IBM used "I" as first character (for what else then IBM) and "Z" can be assumed to be Zotlabs. These prefixes can contain 3 to 4 alphabetic characters. The following number has four digits and offers potential for structuring. For example, I use number ranges 0100 within GET() and 0200 for POST(). The suffix says something about the importance of the messages. I stands for info, W for warning, E for error, D for disaster and A for action. By the way, a message prefix is also good to use in the html skeletons of the templates, e.g. as <DIV ID="zar234" (at least that's how I used it). Speaking of html. The message identifiers in my examples don't have to be designed optically like in my current UIs. For a more discreet use, the Html Title attribute would be very suitable. Only for now, as a kind of promo for something like qms, my UIs look like this at the moment.
Hope story was not too boring. Keep healthy

qms account invite coding messages notices

email invite / register

Hilmar R (u-462)

Europe, Tue, 14 Jan 2020 14:50:26 +0000

!Zotlabs|Hubzilla Development
As told in the support forum earlier, I want to modify the email invite stuff. The initial reason was to extent some functionality. Now, I see the need to rewrite the stuff at all because of some detected misbehavior. That requires at least to modify the register table, or perhaps to have a table scheme redesign. The question arises because postgres does not support the same kind of modifications as mysql. To add fields to the scheme, mysql allows new columns to be placed in a disired order, while postgres supports only an add to the end. In most cases, the defined order of columns does not matter access times. Thus, the order has only a nice or a less nice look.
Currently, the columns in register are named id, hash, ... etc. Most other tables have more descriptive column names, easier to apply in a more complex query. Thus, the question is, should the column names altered to some like reg_id, reg_hash, ... etc on the occasion?

Current design:

CREATE TABLE 'register' (
 'id' int(10) unsigned NOT NULL AUTO_INCREMENT,
 'hash' char(191) NOT NULL DEFAULT '',
 'created' datetime NOT NULL DEFAULT '0001-01-01 00:00:00',
 'uid' int(10) unsigned NOT NULL DEFAULT '0',
 'password' char(191) NOT NULL DEFAULT '',
 'lang' char(16) NOT NULL DEFAULT '',
 PRIMARY KEY ('id'),
 KEY 'hash' ('hash'),
 KEY 'created' ('created'),
 KEY 'uid' ('uid')
) ENGINE=InnoDB AUTO_INCREMENT=489 DEFAULT CHARSET=utf8mb4;

Proposed design:

CREATE TABLE IF NOT EXISTS 'register' (
 'reg_id' int(10) unsigned NOT NULL AUTO_INCREMENT,
 'reg_hash' char(191) NOT NULL DEFAULT '',
 'reg_email' char(191) NOT NULL DEFAULT '',
 'reg_created' datetime NOT NULL DEFAULT '0001-01-01 00:00:00',
 'reg_expires' datetime NOT NULL DEFAULT '0001-01-01 00:00:00',
 'reg_uid' int(10) unsigned NOT NULL DEFAULT 0 ,
 'reg_password' char(191) NOT NULL DEFAULT '',
 'reg_lang' char(16) NOT NULL DEFAULT '',
 'reg_stuff' json NOT NULL DEFAULT '',
 PRIMARY KEY ('reg_id'),
 KEY 'ix_reg_hash' ('reg_hash'),
 KEY 'ix_reg_email' ('reg_email'),
 KEY 'ix_reg_created' ('reg_created'),
 KEY 'ix_reg_expires' ('reg_expires'),
 KEY 'ix_reg_uid' ('reg_uid')
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

Reasons:

reg_email

is to verify the registration if bound to one email address.

reg_expires

is to check if the invitation does not exceed a given time frame

reg_lang

is to adjust the account according to the language used just during the invitation (note, individual language selection is served when writing and sending the invitations - part of the new stuff).

reg_stuff

is only for any future use, if additional data should be saved for what reason ever. Prevents the need of scheme modifications for some minor changes.

devel email invite register

show all 4 Comments

Hilmar R (u-462)

Tue, 14 Jan 2020 20:39:57 +0000

Thanks for the reply.

The shown tablecreates are only the part for mysql and sure need attention to a DBTYPE_POSTGRES switch in the code, as seen in Zotlaps/Update/

Initalization NOT NULL during Inserts is required if no default value is supplied or the default doesn't fit.

As far as I have examined (hopefully enough), the affected code beside Zotlabs/Module/Invite.php is
  Zotlabs/Module/Register.php
  Zotlabs/Module/Admin/Accounts.php
  Zotlabs/Module/Admin.php
  include/account.php
  include/connections.php

tend not to use json data types

can full agree and will use text instead (to safe many much work for the next years

)

El Dorado

Wed, 15 Jan 2020 03:37:03 +0000

Sounds like you've got it covered. Thanks for looking into this - it has needed attention for a long time.

Hilmar R (u-462)

Fri, 31 Jan 2020 17:35:55 +0000

After 2 weeks, only want to tell Im still on the road. While new Invite appears rather finished, the dependencies to account are worth to have a strong look to, more then once.
And, does somebody has an idea of a method how to exchange the allocation between made a mistake in 5 seconds to re-find exactly this in 50 minutes?