Notes per Day

+1

This seems a reasonable request. Can you elaborate more on the requirements and work towards a specification. Try to describe things like:
- What settings would it need
- Would you like to be able to disable weekly notes (or at least to not having them rendered)
- How to allow to hide all of this for people that do not need this
- Storage
- Display (on hover only or do you want an indication in the cell that there is additional information, e.g. like the small red triangle in the corner of an Excel cell)

Add permissions to view/edit these and the week notes: as per original request in #341097: More Detailed Information for Each Day.

I personally think weekly notes should be removed in favor of the daily notes. As described in my comment #306467-8: Integrate Availability Calendars with booking process (was: ability to reserve). We could then put everything in the css hover/focus flyout.

I started by making the weekly notes optional. An option has been added to both admin settings and per node settings. notes will not be editable nor shown if this option is disabled. Existing notes will not be deleted. Default is on as this is the existing behaviour.

Is there anyway to get Notes Per day in 6x?

Yes: by implementing it yourself. Start by describing how the user interface is going to look like and what configuration options there will be. You can do so in a comment in this issue. Subsequently implement it in the 6.x-2.x branch, including any necessary changes to the install/update procedures and post it as a patch.

We will incorporate your patch if:
- it follows coding guidelines
- there is an upgrade path
- the feature is backwards compatible: in this case that probably means being optional.

You (and your company/client) will be properly attributed.

I dont know the first thing about module coding.

I dont know the first thing about module coding.

Then start with the first activities:
- specification of functionality
- specification of UI
- configuration options

Reactivating this issue for 7.x-3.x. Backporting to 6.x is out of the question.

We still would like input form others how to do this...

here are my thought about the feature:

- What settings would it need
* enable / disables display of note per week and / or day per role (in my case the authenticated user needs to have it shown, even better by a total list of all notes from all items - i'm building a reservations system, the anonymous user should not be able to see the notes)
- Would you like to be able to disable weekly notes (or at least to not having them rendered)
* yes
- How to allow to hide all of this for people that do not need this
* in the drupal permissions system
- Storage
* per calendar per content item (??)
- Display (on hover only or do you want an indication in the cell that there is additional information, e.g. like the small red triangle in the corner of an Excel cell)
* can it me made into a setting?

hope this helps

@ronajon: did you already have a look at the Rooms module. It looks like your notes resemble booking information. That module has more distinct displays for admin versus visitor. But currently it assumes 1 admin to handle all accommodation which does not fit the rental sites but might fit your situation.

Thanks for the input.

#1313872: Improving the CSS styles and calendar display. posts some CSS that can be useful for this issue, so cross-linking as a reminder.

So, basically we need to make new db column in field schema, named "note" or "description". Then make adding, editing UI for this and represent this data on calendar using popup. Correct me if I'm wrong on any of this stuff, but that's my basic understanding.

@fietserwin, can you give more info on this request. I want to help implementing this feature on D7. Thanks.

It is notes per day, or notes per week. We could even talk about notes per month, but let's forget that for now. So the data model will be a bit more complex than just adding a column to the field schema, as that would just give you a note per calendar.

So to start, I think we should go for a separate table indexed by cid (int) and date (date or varchar(10) in the fomat yyyy-mm-dd) and that holds a note column (longtext or varchar(?)). If we choose varchar(10) as type for date we can store notes per day (yyyy-mm-dd) as well as notes per week (yyyy-ww), they will never clash. So let's do that.

But what about translating a note? We should support that, so we either have to add a language column to the index or rely on i18n_string for that.

The former means that we will have to build translation into our own UI, the latter means that we piss of our editors and have to write code to interact with i18n_string.

If we add it to our own table: In field tables the language column is is a varchar(32) but in the languages table (and locale_sources) this is a varchar(12). Both are long enough to hold the 2-character iso-code used in Drupal to identify languages or the "und" string to define "no language" (LANGUAGE_NONE).

Thus the data model becomes:
table: availability_calendars_notes:
cid: int *
date: varchar(10) *
[language: varchar(12) *]
note: varchar(500)
(* = part of PK, [] = TBD)

C(R)UD UI:
TBD, but I think this can be done in a sub-module (together with the data model) that can use theme_preprocess() to add the notes to the theme variables.

Displaying UI:
- TBD. This will be part of the theming of this module and will thus be part of this module.
- Notes per month can be displayed in the header column (instead of or along with the weeknumber)
- Notes per day could be rendered as the title attribute for the day cells or as a more advanced popup (does jquery (UI) offer something like this?). BTW: this will influence what markup we allow in our notes: plain text only if we use the title attribute or a bit more advanced markup in th other case.

What do you think?

this rather detailed answer indicates that I am willing to cooperate and add this feature to this module, but as always, as long as it constructed generic enough to be useful in more use cases than your own :)

Seems like a plan.

To sum up, we have to create submodule "availability_calendar_notes" and have all functionality and logic related there. Data model seems reasonable and column details can be sorted out.

CRUD UI. I think that this should tie into existing functionality. Screenshots, just for getting into same page:

Display UI. I think we should use some jQuery plugin for showing notes as tooltips on each day rather than going native. Rough screenshot:

Ok, so what are next steps for getting the ball rolling? Maby, creating separate submodule project page, where we can discuss a bit more about specific details?

Some remarks:
- 1 addition: to have month notes as well, we could use yyyy-mm for months, yyyy-Www for weeks and yyyy-mm-dd for days. Querying for a range is still doable but can be made easier by adding a type field: 1 char: 'm'' for month notes, 'w' for week notes, 'd' for day notes. So let's do that and have the API allow all of this.
- So jquey offers some nice toolltips: let's go for that: nice styling is important here. Thuis also means we can go for text with markup. Of course, We'll do a drupal_filter

And regarding splitting it into a sub-module and how to define the interaction between the main module and the sub-module. I see 2 ways:

- The main module's theme functions are extended to allow for arrays of notes and does render them. A theme_preprocess in the sub-module can fill the arrays.
- The main module defines a hook in its theme_availability_calendar_month() function and hands off the caption and list of day cells to that hook.

// actual code ...
  $caption = format_date(mktime(12, 0, 0, $month, 1, $year), 'availability_calendar_month_caption');
  $cells = availability_calendar_month_cells($year, $month, $availability, $settings);
...
    $cells[$day_iso] = array('data' => $cell_contents, 'class' => $classes);

The hook would pass on $caption and $cells (being an array indexed by 'yyyy-mm-dd' keys and containing data to create a table cell in theme('table')).

Considerations:
- Allow/render notes on all calendar fields or is this a per calendar field setting? (Decision
- Render notes on the widget and the formatter or should this be configurable as well (notes only visible to the editor?)

To continue:

1. Decide on the interaction between main and sub module. I think I prefer the 2nd way, thus a hook called by theme_availability_calendar_month().
2. Adapt main module.
3. Create a sandbox project for the ongoing work.
4. Version 0.1 should define and implement the API. The API defines crud operations on the notes packed in nice functions (create($cid, $period_type, $period, $note), get($cid, $period_type, $from , $to), get_day_notes($cid, $from, $to), get_week_notes(), get_month_notes(), delete_notes($cid, $period_type, $from , $to), delete_week_notes() , ... See availability_calendar.inc for example code. These API functions should be the only way to interact with the DB.
5. Version 1 should handles day notes and should be in a releasable state (coding standards, code docs). This can already be incorporated into the project.
6. Version 2 should add week notes and month notes.
7. Version 3 should add translation.

Just a thought on the table schema, wouldn't it be better to indicate what type of note the note is in the schema (using another column) rather than attempting to just format them different in the date column?

Such as:

table: availability_calendars_notes:
cid: int *
[type: char(1)]
date: varchar(10) *
[language: varchar(12) *]
note: varchar(500)
(* = part of PK, [] = TBD)

Where type could be:

d = day
w = week
m = month

That would make a selection of notes for days, weeks, or months only much simpler.

SELECT * FROM {availability_calendars_notes} WHERE type = 'w' AND date LIKE '2014-%'

But IMO, the selection of data from the table still seems a little messy with this schema, it might be better to be more granular with it even. Something like:

table: availability_calendars_notes:
cid: int *
type: char(1)
year: smallint(4) 
month: tinyint(2) 
week: tinyint(2)
day: tinyint(2) 
[language: varchar(12) *]
note: varchar(500)

SELECT * FROM {availability_calendars_notes} WHERE type = 'd' AND year = 2014

Some notes on my proposed schema here.

Type
1 letter to represent the type of note being stored (d, w, m)
Year
4 digits to represent the year.
Month
Up to 2 digits to represent the month.
Week
Up to 2 digits to represent the week of the year (1-52) or possibly the week of the month (1-5) depending on ease of abstraction.
Day
Up to 2 digits to represent the day of the month (1-31) or possibly the day of the year (1-366) again depending on your preference.

Column type selection reasoning
smallint(4) UNSIGNED is 2 bytes and supports a range of 0 to 65535 (adequate for year).
tinyint(2) UNSIGNED is 1 byte and supports a range of 0 to 255 (adequate for month, day and week).
char(1) is 1 byte and could easily be extended (there are more letters in the alphabet) if we ever wanted/needed to add more note types, year (y), century (c), whatever. I choose a letter here since it is easier to remember and work with code-wise than a numeric id or something. An alternative would be to use a relational table with the id and label and then do a join in the select, but I don't see it necessary.
Note of course the smaller sizes when using smallint/tinyint/char in my proposed schema are pretty negligible but it won't hurt to use them. char(N) or varchar(N) could work for any of these if you rather.

Additionally, I think the separate columns allow more flexibility with any possible views integration.

Welcome back Nicolas!

- You are right about the type column, I thought of that after #17 as well, see my 1st remark in #20.
- Having that we can indeed freely choose how to store the actual value for that year, month or day and they now may even clash, thus the W for the week notation could be removed.
- Regarding date representation I chose yyyy-mm-dd as this is perfectly sortable, range queries are easy, and they coincide with those databases that do not have a native date type. So my thought was let's use it here as well.
- For day notes we have the iso-dates readily available (as strings) in the theme function, so easy look-up (after easy querying the whole range)
- For week notes we have the iso week number (1-53) also readily available (if they are to be shown)
- I'm afraid that by splitting year, month and day, querying all day notes from e.g. 2014-01-13 to 2014-03-05 becomes way more complex, one of the reasons it was removed (though the use cases are a bit different).
- Regarding views integration:I think again that 1 field will be easier to handle, but that is more a feeling.

All in all, I think that your first definition from #21 is the way to go.

fietserwin, what you wrote sounds like good reasoning to me. I think the only other suggestion I might have is to change date: varchar(10) * to a fixed, rather than variable, length since you will always insert all the digits date: char(10) *. That will reduce the size of the storage by a byte per row stored.

Great discussion happening. Really nice that I sparked this action from two top project commiters.

From my understanding, I also like #21 first suggested schema. Not really my field of expertise, I'm more confident in your decisions.

Now regarding #20, for next steps. I guess we can start working on first two items in a list - interaction functionality and adaptation. And then go into sandbox.

I think that I can help figuring out UI and frontend stuff, testing functionality and etc. Of course, I'm willing to learn new things along the way, so I'm not counting myself of actually coding some logic parts and helping pushing it. Thanks guys!

I'd really like to see this feature.
I'm using the availability calendars on the user's profile so that we can makr whether the user is available for a future project/task. At the moment I have no way to link the user to a project /task, so adding notes would be a useful start to doing this.

I'm aware that my usecase is probably not the normal approach and i don't want to distract from the excellent work being done, so these are a couple of thoughts/ideas based on how I'm using the availability calendars and just seeing if they are valid for future scope or something that won't be considered.

1. Rather than having notes per day/week/month, would it not be better to be able to set a note based on a duration. For example user books 6th feb till 9th Feb and would like to place a comment/note attached to that "selection".

2. Rather than just a note, would it be possible that this could be more generic such as using entity reference or node reference to allow linking to a node? This potentially gives flexibility to use a view to define what is displayed in the popup.

I currently do not have time to code this myself, though I can spare some time to advise, discuss and review.

re #25.1) This request seems more like a booking module, show who/what is booked for what event/task/project. That is not the way this project currently works, see many other feature requests about this subject.

re #25.2) I think that if we manage to do this in a sub-module, and thus were able to separate delivering the notes from rendering them, that would be easily solved by a custom module. Right now, I am not convinced that we should try to generalize it in the way you propose.

that's fine appreciate reviewing my thoughts. :)
I'll also take a look at some of the booking modules to see if they can cater to my use case.

Is "Notes per Day" finally implemented in 7.x-5.x or not?
thanks in advance.