Missing "Physical summary" field when manually creating book

When editing a book, there is a "Physical summary" field that can be specified or left blank for an autogenerated value.

For some reason, when adding a new book via the "Manual entry" form, this field is not present.

This appears to be intentional within the code, but I'm not sure why. I will need to research.

The point of this field is to be automatically generated, so it can only be edited post hoc.

I'm not sure I understand, it seems like there's a bug either way:

* If the field is supposed to allow user editing, then it should be present in "Manual entry" like it is for "Edit books". (This is how the "Summary" field works: the user can either specify a value, or leave the field blank to get an auto-generated value.)

* If the field is only supposed to be automatically generated then it should not be editable under "Edit books".

The field is, by design, automatically-generated and then editable after the fact. That may seem like an odd choice, but it's working as intended.

>6 lorax: this is correct; after you add the book, its value is generated, and then you can edit it.

With the current behavior, in order to manually set this field, the user needs to first create the book without specifying a value, then go back and edit it to fix that field.

I would consider this a bug (or, if intended, a design flaw) since it forces the user to go through several extra steps for no apparent reason.

It seems like it would be simpler to have it work like the "Summary" field, where a user can either set a value or have it be auto-generated by leaving the field blank.

>8 ltji_test: Do you want to input something that isn't going to be auto-generated? Because normally filling or not filling the fields for pages, length, width, etc. is otherwise a way to 'design' the physical summary.

>9 SandraArdnas: I came across this issue when working on a script to import books from JSON data (see https://www.librarything.com/topic/330500). This omission from the manual entry form is an obstacle to properly supporting the "Physical summary" field.

Personally, I don't really care about the physical summary field so I let LT set it automatically.

I'd honestly be scared of letting it remain open during manual entry initially. With the other bad uploads and misappropriation of fields, I'm scared someone would take their review or their book blurb and place it in the physical summary field. Better to have it auto generate first, so they see exactly what goes there, then allow modification after the fact.

>11 gilroy: I don't see why the physical summary field is special in that regard. Actually, it seems relatively harmless as compared to fields like title/author/ISBN, since it only affects the user's own book and not the shared work data.

In fact, as far as I can tell the field is basically useless anyway, since it doesn't seem to be displayed anywhere except when editing a book.

>12 ltji_test: Then let's do away with a useless field. Save some Database space.

>11 gilroy: It would be better then notes ending up as reviews upon import, which actually happens. Physical summary only ever affects the catalogue of one particular member. Why would you care what anyone else has in that field?

>14 SandraArdnas: The bug reports of someone putting things in the wrong field, then complaining that it isn't showing up right and trying to hunt down why it's missing. That's my primary concern. Notes are rather easy to find and move, provided they are both the public fields the user is using. Keeping the summary field and making it open at upload/manual entry, they would be putting a desired public detail into a private field that only they could see. Which would then tax the Admin more, because the common user would have less chance to suss it out.

>15 gilroy: Honestly, I don't foresee the problems you envisage, while OTOH importing unrelated field like notes to the review field is actually quite common and genuinely affects all users. I've personally left several message to people with 500+ reviews that are personal classification notes, prices and such. AFAIR, only one actually responded to a plea to move those to an appropriate field. The rest continue to pretend to be reviews, which is most annoying when there's only one or two reviews for a work, but when you get to them you discover they say OGL.C.154 or $3.90 or some such

>16 SandraArdnas: You do realize Tim has said you don't contact people regarding those bad uploads, right? It's why we got the blue not a review flag in the first place.

And while you may not see it, I do. Which is why I say, if the field is so useless as suggested, we just do away with it entirely.

>17 gilroy: >16 SandraArdnas:

Unless the user has a note on their account saying that they are ok being contacted about this kind of issues of course. But without a specific note, sending a "plea to fix your books" to a user who is already frustrated with the site is going to just chase them even further away and possibly mark LT's notification as spam (which is never a good thing). Which is why Tim had said more than once not to do that... If they post a question asking for help or if you already know the user from the site, that changes things. But cold messaging can be counterproductive and frowned upon.

>17 gilroy: Yeah - bad imports fall over the place - I would not wish to see that field unlocked either - considering how often I see the Publication one used for all kinds of things coming from the import queues, keeping it tight helps. Unless manual add and import can be separated on the programming level of course - having it only on manual import is not a problem....

So people will report bugs if their import falls into physical review, but they don't when it ends up in reviews? In fact, the existing actual problem is to be ignored at all costs, including but not limited to bitchslapping members for any attempts to have them fixed? Wow, that kind of logic just might drive this member away.

>12 ltji_test: Physical description is displayed on the Book details page.

SandraArdnas (#16):

As others have noted, a "plea to fix your books" is not okay. What is acceptable is a note bringing the issue to the user's attention, under the assumption that it is an error they are unaware of. Telling them to take action is not okay - letting them know something may not be where they want it to be is.

>21 lorax: Frankly, I don't see the difference. What is a plea if not bringing the issue to the user's attention? Besides, countless such 'reviews' are flagged as TOS violation by multiple members, but we are splitting hairs now what a note might or not might entail.

Most importantly, I brought up this issue because it is a genuine existing issue that at the same time shows members with such imports DO NOT tax admins with bug reports. I find gilroy's flippantly dismissive comments discourteous to an active contributing member (the OP), so the entire premise of site welfare and not driving members away supposedly behind it is bizarre in that context.

SandraArdnas (#22):

The difference is one of emphasis. It boils down to not asking or suggesting users take actions that benefit other users rather than themselves.

Not okay, as per Tim:

"I see that you've put prices in the review field. They don't belong there, and this makes it harder for others to find actual reviews. Please move them to another field. Thanks!"

Okay, as per Tim:

"I noticed that you have prices in the review field. This happens sometimes when imports get messed up, and I just wanted to let you know so you can move them if that's not where you want them."

The second emphasizes that users can set up their catalogs however they want, and aren't expected to change them for the benefit of others.

>12 ltji_test: >13 gilroy: Physical description summary is one of the column options for viewing in the catalog, and it's useful there, especially if I'm working on a relatively small screen and need to limit the number of fields I show.

I don't know what the use case of it being editable is though, if I'm using it to replace having all the different physical data fields I want to know that it contains the same data they do, so unless editing it also edited them I would really prefer it *wasn't* an option to change it.