grandcomicsdatabase / gcd-django Goto Github PK

There are many examples (FF #1, Action Comics #1) but this was the one that came to mind right now:

Conan the Barbarian #75 homaged in Avengers #28

http://dev.comics.org/bugs/show_bug.cgi?id=294
Reporter: @jochengcd

From time to time a comment is entered by error or should have been a note and
not comment. For an indexer there should be a way to remove a comment before it
is submitted, i.e. while editing.

If a change is sent back this of course should be only applicable for comments
after the sent-back-comment by the approver.

------- Comment #1 From Henry Andrews 2010-05-19 06:23:53 PST [reply] -------
This can be done from the main changeset page. It should not be done from the
individual revision pages as having two forms (one to change the data and one
mess with comments) is likely to lead to confusion when someone deletes a
comment and is suprised that all of the data changes they entered in the main
form are dropped.

Note that "deleting" a comment has two cases:

• There is no state transition attached to the comment (old_state ==
  new_state). In this case, the comment can be deleted entirely.
• There comment is part of a state transition (old_state != new_state). In
  this case, the comment text must be set to the empty string but the database
  row should be left alone to preserve the state change history. Even though I
  think I'm the only person who ever looks at that part :-)

http://dev.comics.org/bugs/show_bug.cgi?id=209
Reporter: @jochengcd

indexer credits from the new OI have to be displayed on the issue page and
integrated with the old information on the series level.

individual issue display is working.
------- Comment #1 From Henry Andrews 2009-11-29 13:45:08 PST [reply] -------
No individual credits are included in the series level box, nor should they be.
------- Comment #2 From Jochen G. 2009-11-29 14:31:32 PST [reply] -------
In the series level box we list the indexers who worked on the issues of a
series at some point. Lots of legacy data which can't assign to issues for the
'old' series.
------- Comment #3 From Henry Andrews 2009-11-29 14:36:50 PST [reply] -------
Yes I'm aware of that. New credits don't go in that box, though. Leave them
there, treat that whole table as immutable. New credits only go in the "most
recently edited" list above that box.
------- Comment #4 From Henry Andrews 2009-11-30 02:21:24 PST [reply] -------
Since the credits are displaying in some form, let's postpone the discussion of
exactly how they should all display until 0.3 dr festus or even kin-der-kids.
------- Comment #5 From Jochen G. 2009-11-30 08:35:59 PST [reply] -------
There is the problem for series where no issues were indexed before. Then
nothing will show since we don't check for the new OI info when deciding if to
show something there at all.

A simple 'or' in the template for the issue page should take care of that.

(Mainly writing this to remember to do that when I am back home)
------- Comment #6 From Peter Croome 2009-11-30 16:25:27 PST [reply] -------
I was about to open a new bug, but this fits in well here:
The text "Issues in this series have been indexed by:" is a bit confusing.
Henry suggested "This issue may also have been indexed by one or more of:"
which I think covers the craziness of that data perfectly! ;)

Peter
------- Comment #7 From Jochen G. 2010-01-17 16:17:09 PST [reply] -------
We could just decide to display the indexer information for a series only on
the series page. List there somewhere (below the status grids ?) all the
indexer names who did something for this series, be it from the flat file days
(which we have no real way to all assign to issues), from the old OI (which we
should be able to all assign to issues in some way), and from the new OI.

On the issue page only show the ones directly for the issue, with an additional
pointer to 'others have indexed this series' on the series page (or something
like that).

This will lessen the confusion on the issue page.
------- Comment #8 From Jochen G. 2010-08-22 12:27:22 PST [reply] -------
With the coming of change history and the migration we should revisit this.

In particular shall we display the individual credits on the issue pages at
all, or should we display all indexer credits via the change history ?

Not really a tech decision to make, so once more of the log history is deployed
on beta this should be discussed and decided (a board decision after discussion
on main ?)

This also concerns the redesign of our pages, do we need a place in them for
the indexer credits or not.
------- Comment #9 From Henry Andrews 2010-09-19 00:44:02 PST [reply] -------
Even if we don't act on this during 0.4 little nemo, we should keep it in mind
as some of the solutions are potentially quite simple. I'll get Board looking
at this sometime before the release.
------- Comment #10 From Henry Andrews 2010-12-07 05:00:38 PST [reply] -------
Cut from the 0.4 little nemo release.

http://dev.comics.org/bugs/show_bug.cgi?id=289
Reporter: @jochengcd

From
http://dev.comics.org/reviews/r/342/

As in the other version, this should call show_title()

If we want to display "[no title indexed]" in italics instead of "no
title" I can change to show_title() with an additional if title=="[no title
indexed]": title = '<span....

I don't want to mess with it now but I think we could fix up
show_title to handle things better, or make a method that both this and
show_title call, or something. For now keep it like you have it.

http://dev.comics.org/bugs/show_bug.cgi?id=310
Reporter: @handrews

We need code to support changing many items at once using changesets and
revisions properly. Initially, this will be done through scripts, so it needs
to not be tied to HTTP requests at the view layer. In general, we should have
at least some capability for this through the OI, but the UI requirements are
complex and therefore will be covered in a future bug.

The script may move things directly into an "approved" state on the assumption
that the admin running the script will have gotten pre-approval for the change
from the Editors. Being able to generate an HTML page showing what would be
changed (without actually changing things) would be a bonus but not required.

When there is an open changeset/revision in the way, the script should report
that it could not make a change and move on. The report should be written to a
file so that it can be mailed to the editors or otherwise examined by someone
other than the admin running the script. The general plan would be to
periodically run the script until no necessary updates are blocked.

------- Comment #1 From Henry Andrews 2010-05-19 06:38:32 PST [reply] -------
Marking this for the current release in hopes that someone has time to work on
it :-)
I am not doing so at this time so I'm releasing it back to the list.

------- Comment #2 From Ralf Haring 2010-06-10 21:35:46 PST [reply] -------
*** Bug 361 has been marked as a duplicate of this bug. ***

------- Comment #3 From Jochen G. 2010-08-28 21:14:05 PST [reply] -------
Working on bulk changes for issues.
Only fields which are the same for all issues under consideration (identified
via advanced search) can be changed. Here the compare/approval process is
straightforward since each issue has the same changes.

Other bulk changes would need further work, which I most likely won't work on
for now.

------- Comment #4 From Jochen G. 2010-09-11 11:47:03 PST [reply] -------
http://reviews.comics.org/r/554/

adds bulk changes for issue level information

------- Comment #5 From Jochen G. 2010-11-02 11:03:26 PST [reply] -------
Further work on bulk changes will be in future releases.

http://dev.comics.org/bugs/show_bug.cgi?id=71
reporter: @handrews

Description: [reply] Opened: 2009-08-27 00:52 PST
It would be less confusing if pages didn't link to themselves. This mostly
happens with the series/issue/publisher/imprint name bars at the top, which are
generic bits of code and don't know which link is the self-link. So they would
have to be "told" in order to conditionalize the links. This would be nice to
have, but is not critical to have before shipping, I think.

On the new search results page, you can sort by Relevance/Year/Country. If you drill into one of the filters, you can sort by Relevance/Alpha/Chrono/Country.

It's cosmetic, but Chrono and Year should probably be consistent. And is Alphabetic omitted on purpose?

http://dev.comics.org/bugs/show_bug.cgi?id=76
reporter: @ralfharing

Description: [reply] Opened: 2009-09-02 01:07 PST
From Ray comes a reminder that we wanted to create a web form to submit contact
list info instead of using a mailto link. This way we can reduce spam to the
contact list.

------- Comment #1 From Ralf Haring 2009-09-28 19:29:47 PST [reply] -------
*** Bug 129 has been marked as a duplicate of this bug. ***

------- Comment #2 From Ralf Haring 2009-09-28 19:39:12 PST [reply] -------
from 129:

It should have, at least, the following fields:

• Name
• Email Address
• Text

On the technical side, there is a django app doing this:
http://bitbucket.org/ubernostrum/django-contact-form/overview/
it is released under the BSD license, so it is safe for us.

------- Comment #3 From Jochen G. 2010-05-08 08:23:44 PST [reply] -------
An i18n version of the form Ralf found
https://bitbucket.org/zerok/django-contact-form-i18n

------- Comment #4 From Jochen G. 2011-06-07 23:52:46 PST [reply] -------
there are the mentioned and maybe other django addons around we can use. If
someone wants to have a look.

------- Comment #5 From Jochen G. 2012-02-10 21:30:10 PST [reply] -------
this is an extension of the mentioned where also user-to-user is included
https://bitbucket.org/albertoconnor/django-email-form/overview

A search for "urasawa" doesn't return "Naoki Urasawa's Monster".

http://www.comics.org/searchNew/?q=urasawa&selected_facets=facet_model_name_exact:series
http://www.comics.org/series/16761/

http://dev.comics.org/bugs/show_bug.cgi?id=88
Reporter: @ralfharing

Description: [reply] Opened: 2009-09-12 11:16 PST
We currently list stories with no title in many different ways and languages.

[untitled]
[no title]
[ingen tittel]
[geen titel]
[ongetiteld]
[kein deutscher Titel]
[kein Titel]

------- Comment #2 From Jochen G. 2009-09-12 13:34:34 PST [reply] -------
from bug 89:

We also have about 4000 title with the value 'none', this also should be set to
'' since we would display '[no title]' for these ?

Here is also to decide if we want to have a difference between a confirmed no
title (i.e. '[no title]' or 'none' currently in the db) or just an empty
string.

------- Comment #3 From Jochen G. 2009-09-12 13:58:39 PST [reply] -------
from Ralf:
There are around 8070 "[untitled]" and 487 "untitled" and 74
"(untitled)" instances. For "non title" there are 98 with brackets, 25
with nothing, and 3 with parentheses.

------- Comment #4 From Henry Andrews 2009-11-26 02:52:40 PST [reply] -------
I'll add these to my data migration script. I have some of them already, and
some that were not in this list.

------- Comment #5 From Henry Andrews 2009-11-27 13:16:46 PST [reply] -------
On second thought, I don't actually have these in my script, and let's do this
later :-)

------- Comment #6 From Peter Croome 2010-11-05 17:43:04 PST [reply] -------
Also "nessuno" on the Italian comics. I've seen this as both story title and as
Feature.

http://dev.comics.org/bugs/show_bug.cgi?id=383
Reporter: @ralfharing

When we have a credit table, it would be nice to be able to store small images
showing signatures they used.

Many people many add what each volume in a book series collects to the series screen in the notes field. This looks cluttered and should/could be done in a more programmatic manner.

http://www.comics.org/series/21639/

Concerns non-comic publications:
If you fill in the sequence info for a cover sequence without choosing a sequence type and hit save story - it pops up with the need to have a sequence type and that drop down lists all the sequence types and you can choose cover.

A singleton's issue history and series history should all appear together on one page. Right now you click on change history and see the issue history breakdown followed by a link to a separate page for series history.

http://www.comics.org/issue/816334/history/

http://dev.comics.org/bugs/show_bug.cgi?id=380
Reporter: @handrews

Per Sandell observes that Swedish characters sort incorrectly under the default
collation. It seems that the collation may be settable on a per-connection
basis. We should look into using the browser's locale setting to determine the
proper collation for query results.

------- Comment #1 From Jochen G. 2010-03-21 22:42:46 PST [reply] -------
Note that there is the collation for sorting in mysql and (probably) for
sorting in python, see also the related (I think) collation bug for displaying
matching search results.

------- Comment #2 From Henry Andrews 2010-03-21 22:58:02 PST [reply] -------
We don't do sorting in Python. You're thinking about matching, I think. The
difference there is that the mysql collation considers some characters
identical that the python regular expression matching engine considers
separate. Which I suppose is related, but I'm not sure it's quite the same
thing.

For instance (at the moment) the issue http://www.comics.org/issue/510483 just shows a giant grey box at the bottom. The change history at the moment is just Anonymous User which added the issue (and some cover changesets). If someone edits the issue in the interim, some other issue which just has Anonymous User will likely show the same behavior.

http://dev.comics.org/bugs/show_bug.cgi?id=365
Reporter: Jerry Hillegas

Would like the ability to select multiple issues to edit at one time similar to
the table with check boxes in the older version of the GCD.

------- Comment #1 From Ralf Haring 2010-10-15 01:43:06 PST [reply] -------
Jochen, this is the bulk issue edit change and can be closed, right?

------- Comment #2 From Jochen G. 2010-10-15 04:40:07 PST [reply] -------
No, we still need something like a table with check boxes for a series.

For selecting a couple of issues of a series

• for reservation for individual edits
• for a bulk change
• for have/want lists at my.comics.org

------- Comment #3 From Henry Andrews 2010-10-31 01:18:04 PST [reply] -------
I'm going to need this for the kinds of bulk edits I'll need to do for a
project running over on the Timely-Atlas list right now, so I'll try to squeeze
this in. At least the bulk edit case- not the bulk reserve case although that
will be a lot easier to add after I'm done, I think.

------- Comment #4 From Jochen G. 2012-08-02 08:50:12 PST [reply] -------
Henry, did you ever start any coding on this ?

------- Comment #5 From Jochen G. 2014-10-05 17:01:00 PST [reply] -------
http://reviews.comics.org/r/1280/

Sometimes we know that there were 5000 copies printed or whatever. The only place for that right now is notes.

Right now, one approver can effectively lock down a changeset by assigning himself to it. If a user makes changes based upon the approver's comments, only that approver can sign off on them even though many others might be working on the queue and could easily verify that the changes were made and sign off on them themselves. This is particularly problematic if the approver happens not to be around for a while. Then there is a very poor user experience as the changes languish when they don't need to.

After sending a changeset back, the approver should be decoupled from the changeset. Then when the user submits it can be treated in a first-in-first-out manner along with all the other changes. Whoever sees it first can approve it. (They'll obviously see the previous comments and can make their own judgement about whether they want to let it wait. Some changes will surely be best handled that way. But right now we needlessly handicap the normal workflow.)

http://dev.comics.org/bugs/show_bug.cgi?id=199
Reporter: @adia

Trying to apply an action to an item (publisher, series, issue) which is in a
state the action doesn't apply causes an error. This can happen if you open the
item in two windows simultaneously and try to reapply an action after you have
already applied it. For example:

• Submitting an already submitted change
• Discarding an already discarded change
• Trying to re-edit a change already submitted or discarded

Not sure if it's worth it trying to fix this at this point, since I don't think
it can happen easily with normal usage, but opening a bug nevertheless.
------- Comment 1 From Henry Andrews 2009-11-30 04:16:16 PST [reply] -------
As long as you get an actual error page instead of a generic 500 error (the
"something went wrong" page) this is the expected behavior. What else would
you expect the system to do? (Re)Applying the action would be incorrect.
------- Comment 2 From Alexandros Diamantidis 2009-11-30 05:05:00 PST [reply] -------
Sorry, I wasn't clear: the error is indeed a 500 / internal server error
currently, not a normal error page, which is what I'd expect.
------- Comment 3 From Jochen G. 2009-12-02 16:58:07 PST [reply] -------
Why are raising ValueErrors if the states are not in expected states for
certain actions.

This is fine for debugging and testing, but maybe this should go to the generic
error page on production ?
------- Comment 4 From Henry Andrews 2009-12-02 16:59:51 PST [reply] -------
Because I wrote that part a long time ago and hadn't sorted out any error
handling strategy. It should all be updated to use render_error() or whatever
else is appropriate.
------- Comment 5 From Henry Andrews 2009-12-02 17:00:19 PST [reply] -------
Which might mean catching ValueError in the view layer, btw. Not sure what
works best.
------- Comment 6 From Jochen G. 2009-12-02 17:18:27 PST [reply] -------
Probably better in the models.py. Some routines can raise ValueError for
several reasons.

We might want to make

if settings.BETA:
raise ValueError, text
else:
render_error(text, redirect=False)

to still have debugging on dev.
------- Comment 7 From Henry Andrews 2009-12-02 18:00:18 PST [reply] -------
models.py should definitely not be aware of request objects or render_error().
That should happen exclusively at the view layer. Even for testing, a good
error message is preferred over an exception, as it pinpoints a real case for
us instead of "oops, something unexpected blew up".
------- Comment 8 From Jochen G. 2009-12-04 05:04:23 PST [reply] -------
agree with models.py

for dev:
exceptions have the advantage that we will know about it, not just the tester.

so this would mean we have to write try everywhere in oi view code where the
model routines will get called ?
------- Comment 9 From Henry Andrews 2009-12-04 16:27:35 PST [reply] -------
About exceptions: When it's a correct error (i.e. the user tried to do
something that we know about and intentionally do not support, like edit a
change that's in the wrong state), as a dev I do not want to know about it.
It means that the code is doing what it should, which is returning an error. I
only want to know if we've gone down a code path we did not anticipate with a
proper error message.

As far as try/except blocks, I'm not even sure that the validation that's being
done in the model layer belongs there. Let's reconsider that aspect of the
design in kin-der-kids. As Alexandros noted, for now it's not too critical
because if you get to this point you've done something odd anyway. If we had
less time pressure I'd fix it before release but oh well.
------- Comment 10 From Ralf Haring 2009-12-04 16:48:51 PST [reply] -------
The case that brought this problem to light for me was two editors looking at
the pending queue trying to assign an item to themselves.
------- Comment 11 From Jochen G. 2009-12-04 16:55:35 PST [reply] -------
(In reply to comment 9)

About exceptions: When it's a correct error (i.e. the user tried to do
something that we know about and intentionally do not support, like edit a
change that's in the wrong state), as a dev I do not want to know about it.
It means that the code is doing what it should, which is returning an error. I
only want to know if we've gone down a code path we did not anticipate with a
proper error message.

What I mean is that this distinction isn't always clear cut.

Anyway, let's look into this later. The changed cache behaviour on the queue
page will reduce the possible situations as well.
------- Comment 12 From Henry Andrews 2010-02-26 12:20:27 PST [reply] -------
*** Bug 362 has been marked as a duplicate of this bug. ***
------- Comment 13 From Henry Andrews 2010-05-19 05:59:49 PST [reply] -------
*** Bug 367 has been marked as a duplicate of this bug. ***
------- Comment 14 From Henry Andrews 2010-09-02 04:17:34 PST [reply] -------
*** Bug 459 has been marked as a duplicate of this bug. ***
------- Comment 15 From Alexandros Diamantidis 2010-11-04 17:21:44 PST [reply] -------
Another source of errors of this sort I just encountered on beta: Open an issue
in two browser windows, press "Edit" on one, "Delete" on the other - result:
Internal Server Error. This only happens with indexed issues. With unindexed
issues, you are correctly informed that you can't do that because the issue is
reserved.
------- Comment 16 From Ralf Haring 2010-11-04 17:36:52 PST [reply] -------
by indexed vs. unindexed do you mean issues with and without sequences?
------- Comment 17 From Alexandros Diamantidis 2010-11-04 18:01:36 PST [reply] -------
Hmm... That's what I meant, but I hadn't actually done many tests, and now that
I try it again, I see that's not it.

I now tried this with some other issues, and the only one to exhibit the error
is:

http://beta.comics.org/issue/128584/
------- Comment 18 From Ralf Haring 2010-11-04 18:08:03 PST [reply] -------
I thought it might be a problem with single-issue series but others seem fine.
I tried that issue on beta and locally got the same error. It looks like it is
because of non-ascii characters in the series name. I tried some German issues
in series with umlauts and ß and got the same error.
------- Comment 19 From Ralf Haring 2010-11-04 18:53:38 PST [reply] -------
This actually occurs when you try to do Edit from two windows as well, so it's
not specific to Deletes.
------- Comment 20 From Ralf Haring 2010-11-04 20:38:56 PST [reply] -------
(In reply to comment 15)

Another source of errors of this sort I just encountered on beta: Open an issue
in two browser windows, press "Edit" on one, "Delete" on the other - result:
Internal Server Error. This only happens with indexed issues. With unindexed
issues, you are correctly informed that you can't do that because the issue is
reserved.

This part of this bug is handled by http://reviews.comics.org/r/640 (part of
0.4 little-nemo). Not sure about the previously reported parts.

http://dev.comics.org/bugs/show_bug.cgi?id=438
Reporter: @adia

Non-ASCII characters in many database entries have been misencoded, with the
result that they appear as other characters. The mistakes are not consistent,
with the result that a specific character in the database might stand for
various other correct ones, or might actually be correct as it is.

A discussion can be found here:

http://groups.google.com/group/gcd-tech/browse_thread/thread/5c990cc7c7a0af9e/20674b1927083f77

We might fix those mistakes either by running updates directly on the database:
there is a couple of scripts attached to the thread above that can be updated
for the current schema.

Alternatively, it might be better to use the mass change framework from bug 310 (now issue #49 ) when it's implemented.

This would be relevant for lots of manga, "right-to-left unflipped" vs. "left-to-right flipped".

http://dev.comics.org/bugs/show_bug.cgi?id=212
Reporter: @handrews

Some good ideas on this from various sources:

From Ray via the main list:

--- quoting Ray --
It would be great to have the ability to add multiple issues on any series that
has no issue numbers, but we use instead some other option to identify the
issues.

I am thinking about those hundreds of weekly issues of any number of British
comics that have no issue numbers and we use the cover date as the defacto
issue number to identify the difference in issues. Often with stuff like
1964/03/03 [1], etc... as the issue number.

If there is anyways to automate stuff like that somehow, would help get a lot
more Brit books into the database.
--- end quote --

From Jochen in code reviews:
European series that skip numbers in a pattern, i.e. 1/1995, 3/1995, 5/1995...

From me:
Series that count backwards
Series that use predictable whole numbers on the cover with issue/volume in the
indicia, i.e. v2#1 [13], v2#2 [14], etc. although that won't be as much of an
issue in New Fun. But that's a ways off as it's one of the more complex
changes.
------- Comment #1 From Mark Gordon 2009-12-09 13:27:39 PST [reply] -------
Gentlemen,
I've come across several series from the publisher EBAL that maintain issue
numbers relevant to the actual year published. What makes this most distressing
is several of these series jumps issue numbers or issue years. For example you
could have issues 1950 to 1954, then returning to 1962 to 1974, then ending
with 1979 and 1980.

I've listed these series simply as the years for issue numbers in hopes this
can be changed in the year 2010.

I will keep track of all series that I create with this particular exception
and return to it when the tech team is ready to write code to correct them.

Thank you.
Mark

Similar to series, publishers would benefit from optionally ignorable leading articles, e.g. http://www.comics.org/publisher/4871 is currently "Humanoïdes Associés, Les" so that it sorts under H.

http://dev.comics.org/bugs/show_bug.cgi?id=361
Reporter: @ralfharing

Couldn't find a bug for this, but it would be helpful to be able to apply a
change for a given field(s) to multiple items in one swoop instead of item by
item, for instance changing the brand field of issues 1-20 to XXX and issues
21-54 to YYY.

------- Comment #1 From Henry Andrews 2010-05-21 07:46:16 PST [reply] -------
Non-trivial and not scheduled for immediate work. Higher than average
priority, though.

------- Comment #2 From Ralf Haring 2010-06-10 21:35:46 PST [reply] -------

*** This bug has been marked as a duplicate of bug 310 ***

------- Comment #3 From Henry Andrews 2010-06-10 22:59:40 PST [reply] -------
I had actually viewed this as a request for a particular front-end usage of the
back-end work requested by bug #310. Implementing 310 just on the server side
will still give us a lot of benefit, as other features like cascading deletes
depend on them.

However, the UI for a feature like this is non-trivial and separate from the
back-end work.

http://dev.comics.org/bugs/show_bug.cgi?id=429
Reporter: @jochengcd

To make this more useful we would also have to think about
emailing not just the indexer, but other wanting it as well, i.e. a 'watch'
functionality for an object or a changeset.

------- Comment #1 From Henry Andrews 2010-06-30 18:55:50 PST [reply] -------
Ideally one can watch an object or an object and all of its children in the
system in general (or really, watch anything matching a particular query).
We'll probably want to split some of that out into separate bugs if/when we
decided to implement it, but might as well note it here for now.

The quick solution for changesets is to consider anyone who has commented to be
on the watch list, and to allow "watching" by tacking on an empty comment.

http://dev.comics.org/bugs/show_bug.cgi?id=316
Reporter: @handrews

The sort by issue number feature currently only works if all issue numbers are
integers. This causes people to renumber issues so that they will sort, and
then go back and change the numbers back, which leaves the series in a
confusing state in the meantime.

Since sort by issue number now only goes to a preview page, it should sort all
of the integer issues and shove the rest to the end, sorted lexicographically.
The user can then use the manual sort adjustments on the exception numbers,
just as when sorting by key date with missing or ambiguous key dates.

------- Comment #1 From Jochen G. 2010-01-25 06:24:51 PST [reply] -------
It should be optional if the numbered issues are in the beginning or end.

I am reasonably sure there are series who used volume style numbering first and
sequential numbering later, and vice versa of course.

------- Comment #2 From Henry Andrews 2010-01-25 21:14:33 PST [reply] -------
volume-based or annual things are generally not going to sort correctly anyway.
The point is you can use the per-issue to fix the sorting, so I'm disinclined
to complicate things with extra options on the page.

------- Comment #3 From Jochen G. 2010-01-28 02:41:43 PST [reply] -------
I wouldn't call a select button complicated.

Wouldn't yearly based numbers sort correctly when doing lexicographically from
the right ?

------- Comment #4 From Ralf Haring 2010-01-28 08:47:17 PST [reply] -------
You mean selecting a subset of issues and telling it "just sort these by method
X"?

------- Comment #5 From Henry Andrews 2010-01-28 10:18:52 PST [reply] -------
Ralf: No, I mean "do the best you can with method X and stuff the rest at the
end".
Jochen: By "complicated" I mean "more complicated than not doing it", by which
I mean "I don't want to spend time on this at all but I'd rather do that than
have people push incorrect issue numbers live on the site so that they can use
sorting shortcuts", which really bothers me.

------- Comment #6 From Ralf Haring 2010-01-28 10:27:16 PST [reply] -------
I should have been clearer. I was responding to Jochen.

------- Comment #7 From Jochen G. 2010-01-28 14:14:35 PST [reply] -------
Ah, that form of complicated. Fine with me (and I never actually saw someone
renumbering for sorting purposes...)

------- Comment #8 From Ralf Haring 2010-01-28 14:53:02 PST [reply] -------
That would have been me. :-)

http://errors.comics.org/show_bug.cgi?id=2816

Right now the cover approval flow dumps the user onto the pending cover page. However, if the user navigated there from the regular pending queue it feels like you probably want to return there instead.

When editing an issue, there is a button to "add variant issue". Once this is done, there is no way to remove that new variant. Just as you can undo other changes - including fresh additions like sequences - it seems like a reasonable expectation that you could undo that without having to discard the changeset entirely.

http://dev.comics.org/bugs/show_bug.cgi?id=426
Reporter: @jochengcd

Similar to the series details page for the issue data, we could think about
such a page for the creator credits.

It would involve a variation of:

• Show the writer/penciller/inker or feature or more or less, this should be selectable in some form.
• Either story or cover or both.
• Either one (first ? longest ?) or all stories.

Useful for series with typically one story but changing creators.

------- Comment #1 From Henry Andrews 2010-06-22 22:37:55 PST [reply] -------
I should comment that I have 10 or 12 different sort of overview maps like this
that I want to do.

This is trickier than it sounds because it's at a story level not series level,
so good visualization is much more difficult (making both the issue and
stories just vertical entries is not a good visualization).

A lot of what you really want is a map based on feature, optionally
feature-as-appears-in-series.

------- Comment #2 From Henry Andrews 2010-06-22 22:39:01 PST [reply] -------
These sorts of overview maps, btw, and data visualization in general, were why
I started writing code for the GCD. All this other crap was just to be able to
write data visualization stuff ;-)

http://dev.comics.org/bugs/show_bug.cgi?id=136
Reporter @ralfharing

from Jon: "The advanced search field lets you specify countries and languages -
please restrict those lists to values actually in the database. Listing
everything for search is overkill."

http://dev.comics.org/bugs/show_bug.cgi?id=60
Reporter: @andresin

Current name in DB => Corrected name

Credit: writer
"Rafael Marin" => "Rafael Marín"

Credit: pencils/inks/color
"Sergio Aragones" => "Sergio Aragonés"
"Ramon Bachs" => "Ramón Bachs"
"Daniel Acuna" => "Daniel Acuña"
"Solano Lopez" => "Francisco Solano López"
"Francisco Solano Lopez" => "Francisco Solano López"
"Alvaro Lopez" => "Álvaro López"
"David Lopez" => "David López"
"Julian Lopez" => "Julián López"
"German Garcia" => "Germán García"
"Juan Jose Ryp" => "Juan José Ryp"
"Jesus Merino" => "Jesús Merino"
"Jose Gonzalez" => "José González"
"Jose Ortiz" => "José Ortiz"
"Victor Santos" => "Víctor Santos"
"Javier Rodriguez" => "Javier Rodríguez"
"Roger Bonet Martinez" => "Roger Bonet Martínez"

From my day-work I know that for the csv file to be open properly (with international characters) in ms-office it needs to:

• be in "UTF-16LE" encoding,
• has a proper BOM marker at the begining, namely there has to be 0xfeff written before any text.

It should works this way in LibreOffice also.
Few sample lines of code (in java) which do that (and need to be translated into python):

    externalContext.setResponseCharacterEncoding("UTF-16LE");
    externalContext.setResponseContentType("text/csv");
    externalContext.setResponseHeader("Content-disposition", "attachment;filename="+ filename + ".csv");
    writer.write(0xfeff);

http://dev.comics.org/bugs/show_bug.cgi?id=159
Reporter: @handrews

Here's the email from the editors' list:

There are two real issues address here: shared accounts and accounts on behalf
of others. There are no doubt more of both types of accounts (including the
I.N.D.U.C.K.S. accounts) that just don't show up on this list because they
don't duplicate anyone's email. Or just don't have an email address associated
with them (a whole different problem).

Both of these have fairly similar solutions- the only difference is in how they
might affect accounting how many indexes a person has contributed. In both
cases, whoever is entering the data logs in as their own user, and then adds
extra users to the reservation.

• A user is added to the "on behalf of" field if the person entering the data
  is entering it without change. So if I enter an index on behalf of Michael
  Vassallo, it should appear as credited to Michael Vassallo (but if you look in
  the change history details you'll see that I entered the data).
• A user is added to the "with" field if the index or correction was a joint
  effort. So if an index is the joint work of Jim Vadeboncoeur, Jr., Hames Ware
  and Henry Steele, Jim V. would log in under his own account and add Hames Ware
  and Henry Steele to the "with" field. The index would show up as credited to
  all three of them, and the change history details would show that Jim V
  actually did the typing.

This would let us get rid of the joint accounts, leaving only the "project"
accounts like I.N.D.U.C.K.S. as representing multiple people. But that is OK
because it still represents a single entity (the I.N.D.U.C.K.S. project). All
existing joint accounts would either be set to inactive (preserving their
credits as is) or we'd split them into single accounts and adjust their credits
accordingly.

------- Comment #2 From Jochen G. 2009-10-24 01:22:14 PST [reply] -------
When uploading covers which I got on another site I mostly enter
Jochen Garcke (from comiccover.de) as my name.

Would this fit under the 'with' part ?
I assume here that for cover uploads we want people to be logged in. I am not
sure we have decided on that, that's an editor (board?) decision I would guess
and not a technical one.

------- Comment #3 From Henry Andrews 2009-10-24 01:28:15 PST [reply] -------
I think that folks will need to be logged in for cover uploads. We haven't
specifically discussed that, but we have agreed that uploads need to go through
approval, and that is a lot easier if they're done through user accounts. You
might want to bring it up on the editors' list, though.

In any event, yes I think the "on-behalf-of" field should work for this,
although we'll need a reasonable way to add accounts for crediting other sites,
or have an additional text or URL field for that instead of a user link.

Sometimes it is useful to know in the base templates if it is used in editing vs. display.

We could either set a context variable, or maybe set and use current_app in RequestContext ?

http://dev.comics.org/bugs/show_bug.cgi?id=373
Reporter: Greg Fischer

I'm looking at the list of Brands for Dell, and I wonder if it would be useful
to have a link to the issues that have been checked as having No Brand. It may
answer the question people might have as to why some issues are listed in the
displayed Brand fields.

There is a slight difference in functionality between when users can add variant issues. The assumed base case is that someone else (user X) has an issue reserved. The discrepancy exists depending on whether the issue has a cover uploaded or not.

If there is a cover uploaded, then user Y can visit the "edit covers" link and add a new variant (assuming they have a cover image to upload).

If there is no cover uploaded, then user Y cannot add a new variant.

It would seem desirable for users to be able to add variants at any time, regardless of the state of the base issue and independent of having a cover image for the new variant. Tests on beta show that taking an issue reserved to user X, user Y can manually go to http://www.comics.org/issue//add_variant_issue and submit the form for a new variant successfully. The "submit new variant and edit base issue" box correctly errors out, but should probably not be shown as it is always inapplicable when the base issue is reserved elsewhere.

On an issue's change history page, there is a link to a separate page for cover scan change history. This should appear inline all on one page.

The genre input area on the advanced search should be the same as the picker on the sequence edit screen.

Right now searching for "BPRD" doesn't find anything labeled "B.P.R.D.", which is onerous and unintuitive to type. Same thing with SHIELD and S.H.I.E.L.D. It shouldn't be required to have to type out all those pesky periods.

http://dev.comics.org/bugs/show_bug.cgi?id=196
Reporter: @jochengcd

we use

accounts/profile/(?P<user_id>\d+
in comparison to
accounts/mentor/(?P<indexer_id>

i.e. a mix of user_id and indexer_id

should be user_id

But all the emails till now have the indexer id in the URL so we can't easily change unless we use a new url from now one.

------- Comment #2 From Jochen G. 2010-01-31 07:08:50 PST [reply] -------
We might as well change this now.

Although I am not sure if it should be user_id or indexer_id.

Django Users have a get_absolute_url, but that gives /users/
That can be overwritten with

ABSOLUTE_URL_OVERRIDES = {
'auth.user': lambda o: "/accounts/profile/%d/" % o.id,
}

If we want to use the absolute_url filter we need to do that on the indexer and not the user to get the full name of the user via esc(item) in the filter.

So the get_absolute_url for the indexer should call the get_absolute_url of the corresponding user if we use user_id.

We can use user_id, but many calls actually would go over the indexer model, although we only access the indexer over the user... The name we display comes from the indexer.

Anyway, I don't think that there is a situation where only one of the models would be accessed, or ?

So, should the mentor links be changed to use user_id ? There is the problem with the wrong links in the emails, but if we make the change with the cover OI deployment people will realise that some things have changed and that the old emails shouldn't be used.

Or we use
accounts/profile/(?P<user_id>\d+/mentor/
from now and redirect from
accounts/mentor/(?P<indexer_id>

And then we also should use the absolute_url filter on the queue pages to havelinks to the profile.

------- Comment #3 From Jochen G. 2010-01-31 07:13:06 PST [reply] -------
Or just do
accounts/profile/(?P<user_id>\d+/mentor/
from now and not bother with the redirect. The links in the old emails will get a 404.

------- Comment #4 From Jochen G. 2010-11-02 11:06:08 PST [reply] -------
One of these would be nice, but isn't particularly important bugs.

http://dev.comics.org/bugs/show_bug.cgi?id=391
Reporter: Peter Croome

See thread "403 error" from April 18th, 2010.

403 Error seems to occur when the log-in cookie expires after a page has
already been loaded. So user goes to use "edit" button but gets 403 error. A
more friendly message could be displayed, maybe something about refreshing the
previous page and ensuring you are logged in.

------- Comment #1 From Jochen G. 2012-12-30 21:48:15 PST [reply] -------
It was this error
403 Forbidden

Cross Site Request Forgery detected. Request aborted.

in this thread
https://groups.google.com/forum/#!searchin/gcd-tech/403$20error/gcd-tech/_7zmZkI4BWQ/TRoIJM0wcxsJ

If someone enters a list like "asdf; qwer; zxcv;" it would be nice to strip off trailing semi-colons if they exist the same as any whitespace.

http://dev.comics.org/bugs/show_bug.cgi?id=395
Reporter @jochengcd

Obvious that we want to do this at some point, but as obvious (to us tech
people at least) that we need the new db schema beforehand, this is just to
document that we want to have something in this regard.

Partly from email:

It could be also a big help, if each field's got "guessing system". When you
start to type something on a filed (any field, script/artist/editor etc.),
program would give some suggestions what it could be.

Further, the website could use the existing tables. For example, if I'm adding
a new artist for Tung Metall, the program will already know which artists have
been added to Tung Metall. So, it'll suggest only those artist which are on
database under Tung Metall.

[There were more comments in Bugzilla, but they're all about things that were issues in JavaScript and autocomplete implementations at the time (five years ago)- this stuff is pretty standard these days]

Hi,

I'm looking for information about how to contribute in some translations for the gcd website ?
I've found nothing in the Developper's Guide to the Code page.

Where I can find something ?

Thx

Gilles

http://www.comics.org/changeset/2461584/compare/?collapse=1

Entering a "?" presumably doesn't count, and I guess in initial data that makes sense. Fixing data and changing it into a question mark is presumably an improvement, though.

http://dev.comics.org/bugs/show_bug.cgi?id=425
Reporter: @jochengcd

We want to decouple brands/ind_pubs from their current one-to-many
relationship with pubs. They should be many-to-many A single brand can be used
on items published by multiple publishers over time.

The cover gallery link on the issue page under the cover links to first page of the cover gallery. I think it would be more intuitive if it linked to the appropriate point in the gallery. For series with very many covers it is very difficult to navigate to the correct place. You have to guess where the cover you were just looking at might be.

For instance, http://www.comics.org/issue/43358 would link to http://www.comics.org/series/1749/covers/?page=8 instead of http://www.comics.org/series/1749/covers .

http://dev.comics.org/bugs/show_bug.cgi?id=317
Reporter: @handrews

Darrel McCann requested the ability to find out what indexes have been updated
since the new OI came online, and I think this generalizes into a search
feature by modification time. Or most recent modification time, I suppose.
Should take a start and/or end date+time to combine with other advanced search
features.

------- Comment #1 From Henry Andrews 2010-09-18 00:34:00 PST [reply] -------
I doubt anyone will have time to dig around in the guts of advanced search
before the Board Elections which serve as 0.4 little nemo's deadline. But we
should do this in the Solr search if not before.

------- Comment #2 From Jochen G. 2012-11-17 14:39:48 PST [reply] -------
*** Bug 671 has been marked as a duplicate of this bug. ***

http://dev.comics.org/bugs/show_bug.cgi?id=407
Reporter: @adia

When indexing reprint collections, it would be much more efficient to import
existing data from the reprinted issues. We need a way to do this easily.

One way to do this would be to add an export function, so that one can then
import the exported file to the new index.

A better way would be to tie this into the reprint link system. For example,
when adding sequences to a new issue, maybe there should be a way to add
reprinted stories.

An efficient work-flow for adding multiple reprinted stories might go like
this: first, you visit all reprinted issues one by one, and add all the
required sequences to the cache. Then, while editing the new index, there is a
new button labeled "add reprinted stories". Without adding any stories to the
new index, you press it, and you are presented with a list of all cached
stories. You can now tick all you need, submit the list, and copies of the
original sequences appear in the new index.

This would benefit from the implementation of bug #312 (reordering sequences
should be easier).

An option to copy the existing data to empty fields when adding a reprint to an
existing sequence would also be useful.

------- Comment #1 From Jochen G. 2010-05-15 23:08:04 PST [reply] -------
I think this should be independent from reprints, but similar in workflow.

Sometimes you may just want to copy from a similar story. You still should be
able to generate a reprint link at the same time if you want to.

So the button should read something like 'add copy of existing story'. How to
select this story can be quite similar (if not the same) as the procedure to
select the story for matching reprints. I tried to keep the code for that as
modular as possible and need to rework it a bit more to have it flexible in
this regard.

In other words, once reprint editing/matching/selecting is done quite a bit of
the code for copying story data is there.

------- Comment #2 From Jochen G. 2012-09-20 20:54:21 PST [reply] -------
*** Bug 755 has been marked as a duplicate of this bug. ***

------- Comment #3 From Jochen G. 2013-08-20 04:04:08 PST [reply] -------
*** Bug 817 has been marked as a duplicate of this bug. ***

------- Comment #4 From Peter Croome 2013-08-20 11:41:04 PST [reply] -------
I'm just adding a few keywords here so that when I decide again that I like
this idea, this bug comes up in my search... since obviously I can't be trusted
to remember :)

duplicate sequence
duplication
copying sequence