Move the Export Recipe List button, change it to match the Export CSV
button on the layer detail page and put the Tools menu back (useful for
accessing the Admin site if not just for consistency). The Submit Layer
button remains hidden.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
I'm not sure when or how they got broken but the sorting arrows were
overlapping the text, so move them back into the proper location, 8px
from the right of the column.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Add links to the same recipe in other branches in the recipe detail page
(and RRS recipe detail page) so that you can see which versions are
available in other branches and drill down to the detail if you want to.
Implements [YOCTO #13019].
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If someone adds you as a maintainer of a layer as a matter of courtesy
it would be nice if you get an email.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Hack the dropdown HTML to fix the dropdown menu appearing at the bottom
of the "Duplicate recipes" section (which may be below the bottom of the
browser window). This is probably not the correct fix, but it works.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Send the current URL path as a parameter to the login URL so that after
successfully logging in, you come back to where you were beforehand.
Also hide the login/user drop-down on the login page since it's
superfluous.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Use a parameter to pass the current page to the Edit Profile URL so that
saving or cancelling returns you to that same page.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
The layer index has quite a number of layers in it these days and thus
this list is quite long to scroll through. Use the same layer filtering
method as we do on the layers page for the dependencies list.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
The layer index has quite a number of layers in it these days and thus
this list is quite long to scroll through. Use the same layer filtering
method as we do on the layers page, taking care to ensure that the
"select all" and "select none" buttons only affect what you can see when
the layer list is filtered.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
We were using uitablefilter.js to provide live filtering of table rows
based upon a search field value, but it turns out this module really
isn't necessary - we can accomplish the same thing using simple jQuery
code. While we're at it, enable the search field on the layers list page
to work in conjunction with with the drop-down layer type selection, fix
pasting into the search field and refreshing with a search specified.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Using attr('checked') is not reliable, the jQuery documentation
recommends using prop() with jQuery 1.6 or later and it definitely works
more reliably in my testing.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If a user goes to Edit Profile and changes their email address,
deactivate their account temporarily and make them go through the
registration process to confirm that the new email address is in fact
valid and theirs.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Borrow the formatting from some of our other forms which looks much
nicer (and shows field errors properly).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
What we had before was a little bit terse, so add some reasonable text.
Also mention in the confirmation page that sending an email is
predicated on there actually being an account matching the specified
email address (and we deliberately don't specify whether there is or
not, in order to prevent user enumeration).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Use Django's built-in password validators with reasonable settings, and
add a basic complexity validator since there isn't one provided.
Additionally, fix the registration form so that it shows the help text
which includes a description of what the password requirements are.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Users may want to change their usernames for a number of different
reasons, but at the moment we require them to contact an admin to do
that. Provided we validate the new username correctly and add a CAPTCHA
to make automated enumeration difficult, we can add username to the Edit
Profile form and then users can do that any time they wish.
While we're doing this, show a message when the profile is successfully
updated.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Make it possible for users to delete their own account and all associated
information from the database, should they decide they no longer wish to
use it.
(I checked the implications of doing this on our model structure -
anything with a foreign key to user is safe to delete with the exception
of RRS MaintenancePlan.admin which I needed to change on_delete for so
that it doesn't get deleted with the user).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Extend and override the default views so we can extend and override the
default forms to add a CAPTCHA field. This should prevent the automated
account creation requests we've been seeing on layers.openembedded.org
(luckily failing anyway due to bad domain names), but in any case this
also improves security by making it harder to do user enumeration.
For the registration page in particular, because Django's forms logic
tries to be helpful by showing all errors at once, we need to change it
so that if there's an error for the CAPTCHA then you only see that error
and no other - in particular you won't see "that username already
exists" if that is the case.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
nvd3 and its python/django wrappers appear to be no longer actively
maintained, and at least the wrappers were a bit clunky to use. Looking
around for a suitable replacement, Chart.js seems capable, has no
additional dependencies and is fairly simple to use. As a bonus we get
to drop a few Python dependencies from our list.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
It's not too common but there are instances where people have copied
.inc files into their own layer and modified them, and if you are using
such a layer that could result in unexpected behaviour. In order to get
a handle on when this is being done, collect data about all .inc files
and show duplicates in the Duplicates screen.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
When you make changes to the infrastructure it can be useful to test
that email sending is working, since for that to work that involves the
code, Celery, RabbitMQ and SMTP being functional. However, up until now
to run a test you needed to submit a fake layer which is a bit annoying.
Add an explicit "Test email" option to the Tools drop-down for staff
users to allow them to send an email to themselves.
Note: the page will come back when the Celery job has been created, it
does not check and report on the job status - you need to look on the
server side to see that.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
I've come across at least one layer that is now hosted on gitlab.com, so
add support in the layer submission/edit form and import_layer.py for
automatically determining the other fields for gitlab.com URLs.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
On the machines/distros/classes pages, if you type a keyword and then
click "search", and there are no matches, then you click on "browse",
there shouldn't be any search text in the box anymore because you're
viewing all items, so use a bit of javascript to ensure that.
While I'm at it, set reasonable ids for the search field on each page
(including the recipes page, although there is no browse button there so
that is just for consistency).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If there are no search results, focus the search input field and select
any text in it so that the user can just start typing a keyword
immediately.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If you clicked on "Select" then cancelled the modal that appears, then
clicked on "No match" then the title of the modal in the second instance
retains the recipe name from the first time which is wrong. Rearrange
the logic so that this cannot happen (and make it tidier at the same
time).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
This isn't a visual thing, this select element must remain hidden, so it
seems a bit more appropriate to me to specify the style directly on the
element rather than using a CSS class to do it.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
For situations where the user launches a distro comparison update
process and then shortly afterwards realises it is operating with the
wrong configuration (or is otherwise broken) and is going to take a long
time to finish, add a button to the task page to stop the task. This was
tricky to get working, since the default behaviour of Celery's revoke()
would either terminate both the Celery task process along with the update
process (leaving us with no log saved to the database) or worse not even
kill the update process, depending on the signal sent. To avoid this,
send SIGUSR2, trap it in the task process and kill the child process,
returning gracefully. To make that possible I had to rewrite runcmd() to
use subprocess.Popen() instead of subprocess.check_call() as otherwise
we can't get the child's PID.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If a distro comparison update task fails (returning a non-zero value to
indicate as such) we were not able to see this easily from the frontend.
Show success/failure in the form of a label on the task page and general
update list/detail, and if the task fails while we're watching then make
the progress bar go red as well. Also make a distinction between the
process failing (retcode > 0) and being terminated (retcode < 0, e.g.
process was killed).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Provide a mechanism for distro comparison update tasks to display
progress. In practice this means the update command needs to write the
progress percentage to a file and then the log view (which is polled by
the frontend) reads this file. Originally I was going to use a FIFO for
this but that turned out to be a but unreliable; I also tried to use
Celery's state mechanism to pass it back but I simply could not get it
to work. The file-based mechanism is good enough though.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
We were refreshing the page constantly in order to show output while
a task was running, which basically worked but is horrible. Instead,
write the task output to a file and then use AJAX calls to request
whatever output has been written to the file since the last call
and call this roughly every second. Put the output in a scrollable <pre>
element instead of making it the length of the page, and auto-scroll
to the end (unless the user grabs the scrollbar and pulls it upwards -
it may not be immediately obvious that you can do this if there is a lot
of output since you have to pull it up when the scrolling animation is
not running, but it is possible).
An alternative would be to have used some kind of long-lived HTTP
session or a websocket, but those come with their own set of problems
so I elected to use this much simpler method.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If the layer has an actual_branch set, then show it underneath the URL
on the layer detail page so that the reader knows which branch they need
to check out to see what the index shows.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
In a bunch of places we needed to get the branch we were supposed to
be checking out (which is actual_branch if that is set, otherwise the
normal branch name). Add a function to do that.
Additionally, instead of showing the normal branch name next to the
"last update" date, use the result of this new function.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
At the moment the only way to get to the index is to manually type in
the URL, which is a little inconvenent. Add a link to the Tools
drop-down (visible only for users with admin access) that will take you
to it for convenience.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Use a more modern version of Bootstrap and take the opportunity to
upgrade jQuery to the latest version at the same time. This provides
better browser compatibility, moves to MIT license, allows us to make
the site more responsive for different devices in future, and provides
theming capabilities for custom installs among other improvements.
(I chose to upgrade to v3 for now rather than straight to v4 as it was
easier to do this gradually.)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If a maintenance plan has no per-recipe maintainers then we don't show
the maintainer filtering drop-down, but we still had javascript code
that unconditionally tried to access it and of course that failed if it
wasn't there. Disable that as well without per-recipe maintainers.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
I already changed the main layer detail page in
3adddf6a25 to show newlines, but forgot to
do the same in the review detail until now.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If a user doesn't have publish rights and the type of the layer isn't
already "Base" then disallow selecting the Base layer type. Some
submitters are selecting this type for their own layers, but it's pretty
much reserved for openembedded-core and meta-oe (so that they appear at
the top of the layer list).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
We don't want to see the navbar on this page because otherwise it lets
you select branches and click on Stats etc. which doesn't make any sense
in this context.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
We were using the main badge class as a selector here to show the recipe
or maintainer count, and that meant that it also showed up at the top
next to the login button if there were some layers to review. Use a
proper id to stop that from happening.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
When showing the error/warning counts for update records we need to
include any errors/warnings that are shown only in the main update log,
so we need to adjust how these are collected. Use a function rather than
pure aggregation to give a bit more control, and a {% with ... %} block
in the template to avoid the functions being called more than necessary.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Make layerupdate collection slightly more reliable and make it easier
to see when updates have actually been captured:
* Split layerbranch into separate layer and branch fields, since there
may not be a layerbranch in existence but we might want to log an
error relating to the branch and layer.
* Show all layerupdates on the update detail page, not just those with
log messages
* Record before and after revisions and show these in the update detail
and layerupdate detail (with links)
* Record return code of update_layer process
* Highlight layer updates with a non-zero return code, errors or
warnings in the output on the update detail page
* Show duration on the layerupdate detail page
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
On the recipe detail page we provide a link to the actual recipe file
for reference purposes. However, for recipes that include a common .inc
file, many of the definitions of variable values will be inside the
.inc, therefore if you just look at the recipe you won't see the full
picture. Of course you can just go up to the parent directory in the
repository web interface, but for convenience's sake add links to any
files that are included/required by the recipe that are adjacent to
the recipe itself. (We already have the data in the form of the
RecipeFileDependency records that are intended to ensure we know when
the recipe needs to be updated if one of the files it includes changes).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Specifying the covering recipe in the comparison recipe detail page was
always a bit awkward - you could only type the name, if you wanted to
actually find a recipe or look up the currently selected one's details
then you had to open another browser tab/window. To fix this, replace
the form on the comparison recipe detail page with a side-by-side
display of the covering recipe's information, along with a button that
lets you search and then select the covering recipe and at the same time
enter comments or set any of the other cover fields.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If we're collecting this useful info we should really display it. Try to
make the link clickable if possible.
At the same time, add the layerbranch to the list display for Source
objects in the admin site.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Comparison updates might involve some custom fetch process, so provide a
mechanism to register these via settings.py on a per-branch basis. If
an update command is defined for a branch and the logged-in user has the
new "update_comparison_branch" permission, an "Update" button will show
up on the recipes page for the comparison branch for authenticated
users that will trigger the command in the background (as a celery job)
and then show a page that displays the status. The status isn't shown in
real-time since that requires quite a lot of plumbing, but the page at
least auto-refreshes.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If other distro comparison package(s) exist for a recipe being shown in
the RRS recipe detail page, link to the page for each package as well as
any extra URLs.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Add a structure that lets you define a template URL per layer to be
shown per comparison recipe. For example, you could use this to define a
URL template to link to the upstream summary page for the package (e.g.
Fedora's page for the acl package is at
https://apps.fedoraproject.org/packages/acl, so you would use
https://apps.fedoraproject.org/packages/%pn% as the template and then
this would be shown for every package).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Add the ability to export the comparison search results to CSV format in
order to allow importing the data into external tools.
Note: I implemented this in a different way than the earlier recipe CSV
export, i.e. it uses a template to render the CSV instead of a
function-based view with the Python csv module - the reason for this is
we can reuse the same view as we use for producing the search, with all
of the flexibility that gives us.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
When doing the reversed query it's often desirable to exclude recipes
by inherited class, for example those that inherit the packagegroup,
image and meta classes as they don't actually build anything and thus
aren't going to match up with anything in the other distribution.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
