#692 Abstract and Notes without users

[Stéphane Aulery]

When I add or edit an abstract or notes, fields resourcetextAddUserIdNote, resourcetextEditUserIdNote , resourcetextAddUserIdAbstract, resourcetextEditUserIdAbstract stay NULL.

Is this a bug or are these fields no longer used?

In practice I don't find this information relevant for the abstract because it is a single field and not really independent of the resource.

I also don't understand why there is only one rating per resource. Same remark for the Notes dates if it is unique.

[Mark Grimshaw]

They should not stay NULL. Add and edit details will not be displayed if you are not in multi user mode but the user IDs are still written. The fields are definitely still used.

Mark

[Stéphane Aulery]

I enable the multiuser mode to check. Fields stay NULL. I can't find the code responsible for writing these fields

[Mark Grimshaw]

The code for writing the fields if adding or editing an abstract or note of an existing resource is in modules/metadata/EDITMETADATA.php—noteEdit() and abstractEdit().

In a multiuser wikindx, any user with write access can add or edit a not/abstract. Thus it can be useful to know who has done what.

I don't understand this: "I also don't understand why there is only one rating per resource."

Mark

[Stéphane Aulery]

The code for writing the fields if adding or editing an abstract or note of an existing resource is in modules/metadata/EDITMETADATA.php—noteEdit() and abstractEdit().

I can't find anything about Abstract or notes in this code.

In a multiuser wikindx, any user with write access can add or edit a not/abstract. Thus it can be useful to know who has done what.

I understand but the modification of the Abstract and Notes fields can also be done in RESOURCEFORM. Unless special processing is used to verify that only one of these two fields has been modified, or on the contrary neither of these two there will be confusion between the person who modified any field and one of these two fields.

For this to work as expected without complications it should not be possible to add or modify these two fields in RESOURCEFORM.

I don't understand this: "I also don't understand why there is only one rating per resource."

I wanted to say: "I also don't understand why there is only one note per resource."

[Mark Grimshaw]

Hi Stéphane,

On 9 Dec 2024, at 16.45, Stéphane Aulery lkppo@users.sourceforge.net wrote:

The code for writing the fields if adding or editing an abstract or note of an existing resource is in modules/metadata/EDITMETADATA.php—noteEdit() and abstractEdit().

I can't find anything about Abstract or notes in this code.

It’s in noteEdit() and abstractEdit(), both for writing and editing abstracts and notes.

Note that NULL will be written for the user ids in the database (addUser and/or editUser) only if there is no $userId (readOnly user) —this should never happen as such users cannot edit anything.

In a multiuser wikindx, any user with write access can add or edit a not/abstract. Thus it can be useful to know who has done what.

I understand but the modification of the Abstract and Notes fields can also be done in RESOURCEFORM. Unless special processing is used to verify that only one of these two fields has been modified, or on the contrary neither of these two there will be confusion between the person who modified any field and one of these two fields.

For this to work as expected without complications it should not be possible to add or modify these two fields in RESOURCEFORM.

Yes. There are a number of fields that could conceivably be open and edited at the same time by different users. This is something that needs looking at and has been at the back of my mind for some time. If you can suggest a way forward (after these next few updates). . .

I don't understand this: "I also don't understand why there is only one rating per resource."

I wanted to say: "I also don't understand why there is only one note per resource."

It’s entirely up the user/admin how that field is used. My intention, and how I use it, is as a general note that is available to all users. For example, a note that the book is now out of print. If you want more notes you can use quotes, paraphrases, and musings and these are unlimitied but, depending on configuration, might not be viewable by all users.

[Stéphane Aulery]

Note that NULL will be written for the user ids in the database (addUser and/or editUser) only if there is no $userId (readOnly user) —this should never happen as such users cannot edit anything.

Things work as you describe using the EDITMETADATA form, but with RESOURCEFORM the user ids become NULL.

[Mark Grimshaw]

Found it and now fixed in SVN.

[Stéphane Aulery]

There was an error if one of the user ids was already saved with NULL value.

There is another problem in this code. The modification is done in two operations a DELETE then an INSERT. Since they are not in the same transaction if the INSERT fails, the DELETE is not rolled back, and the data is lost. Which happened to me.

To fix there are two choices:

• Execute both operations in the same transaction (a single exec contains the code of both queries)
• Replace the DELETE with the "ON DUPLICATE KEY UPDATE" clause in the INSERT

[Stéphane Aulery]

I looked for where the comments are and noticed with horror that they are in the same table as the metadata. This needs to be remedied.

;) OK. I have to ask, what is wrong with that?

Would you mix resources and users in the same table? This is exactly what is done in this case.

The problems I see:

• Understanding the model is more difficult
• The primary key is no longer a true primary key that designates a single entity. Another data is needed to know the context.
• Writing queries is more difficult and more error-prone
• Data is stored unnecessarily (many empty columns)

On the internet you can find many pages explaining the problems that arise from non-normalized data; like this page https://softteco.com/blog/what-is-data-normalization.

[Mark Grimshaw]

You're right of course. And all the issues you list I have come across with this table (especially 2 and 3). Perhaps I had an idea a decade or two ago that it was more efficient having the one table as opposed to multiple tables.

A job for the future.

Mark

[Stéphane Aulery]

Of course we shouldn't deviate from writing the converter for now.

It may happen that depending on the DBMS, the multiplication of joins slows down queries. In practice, DBMSs have improved a lot and this kind of limit does not concern us. And if this happened, as for everything else, we should only optimize based on measurement and in a well-targeted manner.

I want to redesign the db structure so that it is standardized and optimal. The structure is like the foundations of a house, you don't touch it unless you add a room or dig a cellar.

I have already opened three tickets for different angles of attack:

• [#550] Write a db conceptual specification of WIKINDX + business rules
• [#340] Normalize the database (3NF)
• [#559] Restructure the schema to minimize serialized data stored in database

[Stéphane Aulery]

Yes. There are a number of fields that could conceivably be open and edited at the same time by different users. This is something that needs looking at and has been at the back of my mind for some time. If you can suggest a way forward (after these next few updates). . .

I think there are two major questions:

a) Which fields deserve attribution tracking (who and when)?
b) GDPR states that a user can request to delete their account and data. How can we organize data in a way that respects this right?

[Mark Grimshaw]

Re a) I think attribution tracking is important in a multi-user WIKINDX.

Of lesser importance are the resource itself and the abstract and notes—particularly the first two are public knowledge. As an admin, I would like to know who has added what—how active are they, are they inputting data correctly, and so on.

Of more importance is attribution for the metadata: in increasing order of importance, quotes (and comments), paraphrases (and comments), and musings. Comments and musings can be made private to the user or private to a user group.

Re b) The admin can delete a user. The options are described as:

How do you wish to deal with the deleted users' quotes, paraphrases, musings, ideas, and comments (metadata)? Metadata left unchanged will be shown as added by 'Deleted user'. If you choose to delete users' metadata, other users' comments relating to those metadata will also be deleted. A deleted user's resources are not deleted. If you choose not to delete metadata, all private and group musings, comments, and ideas will be made public.

We could give the option to the user themself to delete their data. In both cases (admin or user delete), attribution is important.

Regards,

Mark

[Stéphane Aulery]

a)

Of lesser importance are the resource itself and the abstract and notes—particularly the first two are public knowledge. As an admin, I would like to know who has added what—how active are they, are they inputting data correctly, and so on.

Do you want to know this for each field of a resource?

When you say "are they inputting data correctly" do you mean preserving the previous state of the resources?

Of more importance is attribution for the metadata: in increasing order of importance, quotes (and comments), paraphrases (and comments), and musings. Comments and musings can be made private to the user or private to a user group.

I looked for where the comments are and noticed with horror that they are in the same table as the metadata. This needs to be remedied.

b)

We could give the option to the user themself to delete their data. In both cases (admin or user delete), attribution is important.

Other ideas, taken from Règles de pérennité des comptes LinuxFr.org et données à caractère personnel

1. Establish the list of personal data retained (necessary for GDPR): for us id, password, email, Full name,
2. User can download all their data
3. User can delete their data if it is not essential to the service
4. User can delete their account (sometimes deactivate to allow recovery within a grace period)
5. Automatic or manual deactivation of accounts unused for more than Y years to prevent hacking (recoverable)
6. Automatic or manual deletion of accounts deactivated for more than Y years

[Mark Grimshaw]

On 12 Dec 2024, at 04.12, Stéphane Aulery lkppo@users.sourceforge.net wrote:

a)

Of lesser importance are the resource itself and the abstract and notes—particularly the first two are public knowledge. As an admin, I would like to know who has added what—how active are they, are they inputting data correctly, and so on.

Do you want to know this for each field of a resource?

Not at all. Attribution is separate for a resource and its bibliographic fields, for abstract, for notes, and for all other metadata.

When you say "are they inputting data correctly" do you mean preserving the previous state of the resources?

In the worst scenario, someone who deliberately disrupts the data. Otherwise, someone who consistently makes errors in data input (not everything can be checked automatically—like capitalisation of title words).

I looked for where the comments are and noticed with horror that they are in the same table as the metadata. This needs to be remedied.

;) OK. I have to ask, what is wrong with that?

Mark

[Stéphane Aulery]

Not at all. Attribution is separate for a resource and its bibliographic fields, for abstract, for notes, and for all other metadata.

You described to me what exists. I ask questions to know if it should be more detailed or only historicize what exists.

In the worst scenario, someone who deliberately disrupts the data.

In my opinion we should not worry about this scenario because authentication is needed to modify data, a general backup of the database is enough. If one day WIKINDX was installed to make a large community site then this would be something to consider.

Otherwise, someone who consistently makes errors in data input (not everything can be checked automatically—like capitalisation of title words).

There is a problem of volume and structure.

Any change in the initial structure implies a modification of the audit structure. So it's more complicated to move.

Data generation can be infinite. We need to find strategies to limit it. It is still necessary to manage to describe realistic data control scenarios.