FEATURE REQUEST: Add QSL send/received boxes to "QSL Management" tab.

[m0urs]

I am currently adding a large amount of received QSL cards to Cloudlog and I think of some improvement in the process.

Here is how I am currently doing it:

1. Search for the call sign and click on the result.
2. Open the tab "QSL Management" and upload both front and back page of the scanned QSL card
3. Go to "QSO Detail" tab, click "Edit QSO", switch to QSL tab
4. Set "Received" to "Yes" and choose the correct method (like "Bureau" or "direct" etc.
5. Set "Sent" to "Queued" or "Requested" and choose the correct method (if I need to send a QSL card)

I could think of two improvements:

Proposal 1:

In the "QSL Management" tab, where I can upload the QSL card images, add the possiblity to enter send/received information like in the QSO tab, so it looks somehow like that:

Proposal 2:

Add additional buttons in the "Logbook Advanced" view for the different "Received QSL" options (currently you can only choose the QSL Sent options. However, we will then get man, many buttons in that view (or we can simplify that by using something else instead of buttons?)

What do you think? Or is my workflow too complicated and there is a more simple way already?

[AndreasK79]

These are good suggestions. We have no good work flow for doing this, and I think both suggestions could be added. I have added a few new buttons in the Advanced Logbook (the code has not been merged yet, but will soon be in dev):

We should really figure out something regarding all these buttons, but I am not sure what the best solution is. I have been thinking about some kind of slider for the filters to hide/show, but have not seen a good solution yet.

[AndreasK79]

I added collapse on filters and actions in PR #2227 .

[phl0]

And I added three buttons to the pic upload page: https://github.com/magicbug/Cloudlog/pull/2228. Looks like this:

[magicbug]

And I added three buttons to the pic upload page: #2228. Looks like this:

From a design point of view, I'm not sure this is the solution but I'm not sure how todo it either (doh)

[phl0]

And I added three buttons to the pic upload page: #2228. Looks like this:

From a design point of view, I'm not sure this is the solution but I'm not sure how todo it either (doh)

Let me know if you have a better idea. I had it besides the upload button (seems utterly wide) and below the upload button (seems somewhat strange).

[m0urs]

And I added three buttons to the pic upload page: #2228. Looks like this:

Looks fine for me and I do not have a better idea at the moment. However, I still miss the button for "Queued via bureau" :-) As I wrote, if someone sent me a card and has "PSE QSL" on it, the I would like to have a fast way to mark it as queued for later.

And yes, there is even another button, so maybe someone has a better idea how to handle that.

However, what about to do it the way I supposed in my screenshot? So that you do have the same possibility as we have it in the "QSO" tab?

[phl0]

However, what about to do it the way I supposed in my screenshot? So that you do have the same possibility as we have it in the "QSO" tab?

To be honest I chose the most easy way. And that is using existing JS code to achieve that. But I am not sure about Q/queued. In the log overview we have R/requested. The spec says: "the contacted station has requested a QSL card". See http://adif.org.uk/314/ADIF_314.htm#QSLSent_Enumeration. Is that what you are looking for?

[m0urs]

But I am not sure about Q/queued. In the log overview we have R/requested. The spec says: "the contacted station has requested a QSL card".

Hm, I am using it this way (although not sure if this is the correct way):

I select "Queued" for cards I want to send later via bureau I select "Requested" for cards I want to send later via e-mail (if I get a card via e-mail, I normally send one back the same way)

[phl0]

Hm, I am using it this way (although not sure if this is the correct way):

I select "Queued" for cards I want to send later via bureau I select "Requested" for cards I want to send later via e-mail (if I get a card via e-mail, I normally send one back the same way)

After reading the spec I am also unsure which one to use. Bu both R and Q do deal with paper cards as well as eletronic cards ...

[m0urs]

After reading the spec I am also unsure which one to use. Bu both R and Q do deal with paper cards as well as eletronic cards

Yes, I also cannot see the difference. That is why I make the difference between Paper QSL and Mail QSL. However, I can also just use "Requested" for Paper QSL and can live with it, if only "Requested" will be made available via button. Mail QSLs are not the case so often.

[phl0]

How about this one? @magicbug @m0urs @AndreasK79

[m0urs]

How about this one? @magicbug @m0urs @AndreasK79

For me this looks great!

[phl0]

For me this looks great!

Does it do for @magicbug as well? :)

[AndreasK79]

It's the best suggestion so far. It's not the prettiest, but it does the job.

[phl0]

Updated and un-drafted PR.

[m0urs]

Should we change "Queued" here also to "Requested" to be consistent with the "QSL Management" tab?

[AndreasK79]

While we're talking about QSL. What about this one in the advanced logbook? Clicking brings up a popup with QSL images uploaded to the QSO.

[m0urs]

While we're talking about QSL. What about this one in the advanced logbook? Clicking brings up a popup with QSL images uploaded to the QSO.

Good idea!

[github-actions[bot]]

Uh oh! @m0urs, the image you shared is missing helpful alt text. Check https://github.com/magicbug/Cloudlog/issues/2214#issuecomment-1615025166.

Alt text is an invisible description that helps screen readers describe images to blind or low-vision users. If you are using markdown to display images, add your alt text inside the brackets of the markdown image.

Learn more about alt text at Basic writing and formatting syntax: images on GitHub Docs.

[phl0]

This bot is ... weird ...

[AndreasK79]

@m0urs did you have a chance to look at the latest changes? Are you missing anything?

[m0urs]

@AndreasK79 Yes, looks fine to me! The only thing is this: https://github.com/magicbug/Cloudlog/issues/2214#issuecomment-1613769492 I think we should be consistent here. So both should be either "Queued" or "Requested". Maybe we go for "Requested" here?

[AndreasK79]

Technically they are not the same. Requested sets R, queued sets Q.

The ADIF spec says:

R | requested | the contacted station has requested a QSL cardthe contacted station has requested the QSO be uploaded to the online service -- | -- | -- Q | queued | an outgoing QSL card has been selected to be senta QSO has been selected to be uploaded to the online service

So what the best approach here is, I don't know.

[phl0]

I still do not get the difference here...

[AndreasK79]

Me neither really.

[m0urs]

As I said, I am currently using "R" for a card to be sent by mail, ad a "Q" for a card to be sent via bureau.

If we look at the ADIF spec I would say I will change this an use

"R" for cards to be sent via bureau "Q" for cards to be sent via mail (electronically/online)

So the buttons should all use "R" for "requested" ad this is the case most of the time (at least for me :-))

[AndreasK79]

Well, you have this for specifying QSL via:

III.B.17 QSL Via Enumeration

Via | Description -- | -- B | bureau D | direct E | electronic M  (import-only) | manager  (import-only)

[m0urs]

I guess the difference is just "R" means, the other station has said it wants a QSL card, and "Q" I have decided to sent a QSL although I do not know if the other station wants one. But you are right they are almost the same.

[m0urs]

@AndreasK79 Yes, I do have that. But I have no possibility to filter in Cloudlog to only get e.g. requested cards via bureau or only requested cards electronically. Or did I miss that? That was the reason I am using R and Q that way.

[AndreasK79]

@m0urs doesn't look like it at the moment, but can easily be added to the advanced logbook. I have added filters for QSL, LoTW, eQSL in dev (and a lot of other stuff).

[m0urs]

That would be ok as well. Nevertheless, the buttons should be consistent and set it everywhere to either Requested or Queued, I still would go for "Requested" as most of the time you will use it because the other station said it wants to have a QSL card.

[m0urs]

@phl0 Could you please have a look at these buttons again:

For me, pressing the request buttons sets correctly the request status to "Requested" but NOT the "Sent Method" field?

[github-actions[bot]]

Uh oh! @m0urs, the image you shared is missing helpful alt text. Check https://github.com/magicbug/Cloudlog/issues/2214#issuecomment-1625586986.

Alt text is an invisible description that helps screen readers describe images to blind or low-vision users. If you are using markdown to display images, add your alt text inside the brackets of the markdown image.

Learn more about alt text at Basic writing and formatting syntax: images on GitHub Docs.

[phl0]

@m0urs Fixed in https://github.com/magicbug/Cloudlog/pull/2284. Pls test.

[m0urs]

Perfect. This does work for me.

You also think about this one: https://github.com/magicbug/Cloudlog/issues/2214#issuecomment-1623174333 ?

[phl0]

You also think about this one: #2214 (comment) ?

We did a little discussion here and we are still unclear what to do. From our understanding "Queue" makes sense in advanced logbook as you would put the cards in the queue for printing them using the labels function for example. On the QSL upload page it makes sense to mark a QSL as "Requested" if your QSO partner has "pse QSL" on his card. So both make sense somehow and I tend to leave it as it is for now.

[m0urs]

Hm, I still cannot understand why to make a difference here. If you mark a card as "Queued" and another card as "Requested" both will appear in the "Print Requested QSL" view (and it also states "Print REQUESTED QSL :-)).

So in the end it does not make a difference and therefore I would still say we should be consistent here and always use "Requested".

Please let me know if the "official decision" is now to leave it as it is as in that case I will change it for me in my fork.

[phl0]

I am not in the position to make an official decision. That would be @magicbug I guess :)